- legal-discuss - lists.openstack.org

CLA Process
by Radcliffe, Mark 12 Jun '14

12 Jun '14

I wanted to provide a summary of the process that we are using to address this issue. After a discussion with Jonathan Bryce and Alan Clark on how best to approach the CLA issue, we have developed the following plan: we need to separate the legal issues and the recommendations. I will start by preparing a memo to provide a legal framework so everyone can understand the legal issues in making this decision. The memo will not provide recommendations, because I think that we need to first agree on the framework before we can assess the options. The goal is to have a finalized framework and recommendations for the Board prior to the July Board meeting. I will be preparing the memo for review by the Legal Affairs Committee for its June 25 meeting. After we get their input, I will make the memo available on the Foundation website for further community review. 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

What are the minimum set of things we believe need the CLA?
by Sean Dague 02 Jun '14

02 Jun '14

An interesting conversation happened when I put up a review to pull in devstack-vagrant to gerrit from github - https://review.openstack.org/#/c/96835/ about what in gerrit requires the CLA. I specifically don't want the CLA required on this, as I've actually gotten organic contributors on github because people found it useful to show up and throw a patch my way (then came back because the round trip from patch submission to merge was very short). This in stark contrast to a conversation I had to have with a new contributor that wanted to patch the README on one of our projects, which I had to sheepishly point to our how to contribute page. Every single time I have one of these conversations I feel terrible, and that I should apologize profusely, because what we ask new contribs to go through is insane. As someone who's contributed to lots of Open Source on my spare time, a CLA is basically something that I'd never bother to touch. About 1/2 our dev tools in openstack-dev are not currently CLA required. It actually makes me wonder if any of them need to be. As these tools typically won't be part of an OpenStack release, it makes me wonder if we can drop the CLA on them entirely as a technical matter. For instance, why is there a CLA on devstack? Given that the board still seems stalled on approving a transition to the contribution framework the development community wants, I wonder if we can at least reduce the number of projects that are creating new developer friction by having a clearer view on what in gerrit we believe has to have the CLA, and ask all the other projects if they want to remove CLA enforcement. -Sean -- Sean Dague http://dague.net

4 6

Re: [legal-discuss] What are the minimum set of things we believe need the CLA?
by Van Lindberg 01 Jun '14

01 Jun '14

I would note that its not surprising that the CLA doesn't make sense to many developers. It wasn't put in place to solve a technical problem. It was put in place to solve legal problems - specifically the problems of patents and non-repudiation of contributions by corporate employees. We can discuss how to best solve those problems, but those are the problems that need to be solved.

2 1

Need for "All rights reserved" in source files ?
by Daniel P. Berrange 27 May '14

27 May '14

In the Nova codebase (and presumably other openstack projects) there is often a statement "All rights reserved" placed on the same line as, or line immediately following, a company's "Copyright" statement. This is not at all consistently applied, eg in Nova, 704 files have 'All rights reserved' but 539 files do not have it: $ git grep --files-with-matches -i 'All rights reserved' -- '*.py' | wc -l 704 $ git grep --files-without-match -i 'All rights reserved' -- '*.py' | wc -l 539 When there are multiple 'Copyright XYZ Corp' lines in the source file header, it isn't entirely clear to whose copyright declaration the 'All rights reserved' statement applies - the one before, the one after, all coyright declarations, or something else... Is there any current legal reason why 'All rights reserved' is needed in source files ? I'm been under the impression this statement is obsolete http://en.wikipedia.org/wiki/All_rights_reserved#Obsolescence Is saying "All rights reserved" even relevant when we have placed the file under the Apache license ? The combo of the 'Copyright XYZ Corp' and the Apache license header should be sufficient to express the copyright status of any source file surely. So I'm wondering if there is any legal reason that prevents us removing the 'All rights reserved' statements from the source files in Nova, and any projects who wish to do a similar cleanup ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

2 2

Re: [legal-discuss] Trivial contributions and CLAs
by Jonathan Bryce 23 Apr '14

23 Apr '14

While individual membership may not be technically required at the bylaws level to submit a contribution, it is required to be eligible to vote in TC and PTL elections. As Thierry mentioned, this was the reasoning when the Foundation formed for creating the tie between the contribution process and individual membership. It was the easiest way to verify the chain of governance eligibility and be able to pull voter lists for technical elections from the contribution logs. If we de-couple, we should make it clear that non-member contributors will not be ATCs. We will also need to develop a new process for determining the subset of contributors who are ATCs and eligible to vote, etc. We might want to look a little more at all the requirements that are fulfilled by the current system moving into implementation to make a pretty significant change. I think this discussion is good and actually is touching on several distinct issues that touch other systems, processes and policies as well. Perhaps it would be useful to put some time on the schedule in Atlanta for a broader governance forum, maybe over lunch one day, where we can get feedback and come up with steps to improve the processes. Jonathan On Apr 23, 2014 8:01 AM, Julie Pichon <jpichon(a)redhat.com> wrote: > > On 23/04/14 13:19, Radcliffe, Mark wrote: > > Julie: > > > > You may not have seen my later post, but I think that deals with your > > concern: > > > > I have never been consulted on this issue, but this interpretation of > > the bylaws is incorrect. ATC is defined to require someone to be an > > Individual Member, but ATC is concerned with voting for the Technical > > Committee, it does not restrict contributions. Anyone, member or > > non-member, can submit a contribution if they have signed the > > relevant CLA. > > Hi Mark, that sounds like great news! At this point, our tooling and > developer documentation enforce this restriction [1] (so it's not > actually possible to submit a patch without joining the Foundation). > I'll file a bug about this that references this discussion. > > Thanks, > > Julie > > [1] > https://wiki.openstack.org/wiki/CLA-FAQ#When_trying_to_sign_the_new_ICLA_an… > > > > > -----Original Message----- From: Julie Pichon > > [mailto:jpichon@redhat.com] Sent: Wednesday, April 23, 2014 3:53 AM > > To: Mark McLoughlin; Richard Fontana Cc: > > legal-discuss(a)lists.openstack.org Subject: Re: [legal-discuss] > > Trivial contributions and CLAs > > > > On 22/04/14 23:10, Mark McLoughlin wrote: > >> On Tue, 2014-04-22 at 14:41 -0400, Richard Fontana wrote: > >>> On Tue, Apr 22, 2014 at 06:24:10PM +0200, Thierry Carrez wrote: > >>>> The origin of this requirement is the definition of 'ATC' > >>>> (active technical contributor). Pre-foundation it was simply > >>>> equivalent to code contributor. You contribute, you are an > >>>> active technical contributor, and therefore you're allowed to > >>>> vote in PTL and PPB/TC elections. > >>>> > >>>> Unfortunately, the Foundation bylaws state (in Appendix 4) that > >>>> ATCs must be individual members of the Foundation. There are > >>>> two ways to read that -- all contributors must be individual > >>>> members, or "ATCs" are the subset of contributors that happen > >>>> to also be individual members. > >>> > >>> I read it the second way, FWIW. > >>> > >>> I also believe that requiring all contributors (even a one-time > >>> contributor of a 'drive-by patch') to be Individual Members > >>> would have been seen as a significant aspect of Foundation > >>> membership policy at the time the Foundation was formed, yet I > >>> can recall no discussion on the issue. I am not saying that it is > >>> something that ought to be stated in the OpenStack Foundation > >>> bylaws necessarily, but I am saying that when the bylaws were > >>> initially drafted, if it was really contemplated that all > >>> contributors would be required to become Individual Members as a > >>> *prerequisite* to making an initial contribution (however > >>> trivial), it would probably have been made explicit in the bylaws > >>> much like the CLA requirement is stated in the IP policy. In > >>> other words I do not believe a policy of "you must join the > >>> Foundation if you want to submit a patch" was contemplated when > >>> the Foundation was formed. If anyone else here thinks I'm wrong > >>> about that, or has a different recollection about this issue, I'd > >>> be happy to hear it. > >>> > >>> Reinforcing that point, if it is correct to read the bylaws as > >>> saying that all contributors must join the Foundation, why > >>> wouldn't the CLAs be unified with the membership agreements? > >>> > >>> I have to emphasize how unusual I believe this policy is. I have > >>> been trying to find some example of an open source > >>> project-related membership foundation (there aren't too many of > >>> these) with a similar policy, with no success. I think Apache > >>> requires project leads to become members by its notion of > >>> membership; that's the closest analogue I've been able to find. > >>> It just strikes me intuitively as *wrong* -- isn't it in effect > >>> coercing potential new contributors into joining an organization > >>> they might not necessarily wish to join, or might not wish to > >>> join until later on? > >> > >> All very well stated and I agree this is rather bizarre. > >> > >> I did know about this before and, interestingly, it was Julie (the > >> Horizon maintainer on bug #1308984[1]) who pointed out how odd > >> this situation is. Perhaps the Horizon project is seeing more > >> instances of this being an issue, or perhaps it came up in the > >> context of the OPW. > > > > Hey Mark, > > > > I often help people get started contributing to open-source and > > explaining "and now you need to join the Foundation" is more > > difficult to explain than even the CLA, as joining a Foundation > > indicates a longer term commitment and belief in the project (in my > > mind and based on experience in other projects). It seemed like > > adding another barrier to making a contribution. > > > > When a volunteer contributor is submitting their first patch to test > > the waters and get a feel for the community, it seems like asking for > > a lot especially when they don't know yet if they'll be sticking > > around. (To the more pragmatic folks it just seems like unnecessary > > bureaucracy.) > > > >> In any case, the way I see it is that a casual contributor should > >> be able to submit small patches with minimal friction and, later if > >> ever, decide they want to be more actively involved, research what > >> the OpenStack Foundation is all about and then join it with a view > >> to being an active member. > > > > That's the order in which "joining a Foundation" would make more > > sense to me, too. > > > > Julie > > > >> > >> One of the elements of disquiet I've heard about our CLA is that > >> contributors must enter into an asymmetric agreement with an > >> entity they have not yet learned to trust ... when they merely want > >> to license their work to the world under the trusted Apache > >> License. This membership requirement takes this a step further by > >> making contributors not only trust the Foundation but also to join > >> it. > >> > >> Mark. > >> > >> [1] - https://bugs.launchpad.net/horizon/+bug/1308984 > > > _______________________________________________ > legal-discuss mailing list > legal-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss

1 0

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 14 Apr '14

14 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 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 25 Mar '14

25 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 22 Mar '14

22 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 21 Mar '14

21 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

3-clause BSD license, Celery
by Russell Bryant 03 Dec '13

03 Dec '13

While reviewing an incubation request for a new project, Barbican [1], I see that it would be adding a new dependency, Celery. As noted below, Celery uses the 3-clause BSD license. On 12/02/2013 11:53 AM, Russell Bryant wrote: >> ** Project must have no library dependencies which effectively restrict how >> the project may be distributed [1] > > http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires > > It looks like the only item here not in the global requirements is > Celery, which is licensed under a 3-clause BSD license. > > https://github.com/celery/celery/blob/master/LICENSE > > A notable point is this clause: > > * Redistributions in binary form must reproduce the above copyright > notice, this list of conditions and the following disclaimer in the > documentation and/or other materials provided with the distribution. > > I'm not sure if we have other dependencies using this license already. > It's also not clear how to interpret this when Python is always > distributed as source. We can take this up on the legal-discuss mailing > list. My questions: 1) Do we already have dependencies that use this license? Do we have a master list somewhere? 2) How does the documentation clause apply for a Python project? 3) If we don't already have dependencies using this license, what do others thing about accepting it (or not) for OpenStack? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-December/020856.html -- Russell Bryant

3 4

Re: [legal-discuss] CLA (was: Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects)
by Jeremy Stanley 22 Oct '13

22 Oct '13

(Disclaimers: I am not a lawyer, which likely explains my lack of interest in perversely pointless paperwork. Also, these opinions are my own and do not necessarily reflect those of my employer. Setting MFT to legal-discuss as a more appropriate forum for these sorts of discussions.) On 2013-10-22 15:11:25 +0200 (+0200), Zane Bitter wrote: [...] > Can't we just write "Copyright OpenStack Contributors"? (Where > 'contributors' means individuals or organisations who have signed > the CLA.) [...] Actually, technically not. There are other avenues through which patches come (posts on mailing lists, attachments to bugs) and I know that from time to time contributors git-am other authors' bug fixes without first asking them to go agree to an OpenStack CLA and prove that they have done so. The actual copyright belongs with the author (or their employer under a work-for-hire agreement), not the contributor who uploaded that work--and they aren't necessarily always the same people. > Gerrit ensures that only OpenStack Contributors (those that have > signed the CLA) can contribute to OpenStack [...] To echo Monty's sentiments earlier in the thread, and also as the person who spear-headed the current CLA enforcement configuration in our project's Gerrit instance, I don't see how our CLAs add anything of value. It's patronizing, almost insulting, to ask developers to pinky-swear that they're authorized to license the code they contribute under the license included with the code they contribute. At best it may provide a warm fuzzy feeling for companies who are unfamiliar with contributing to free software projects, since free software licenses are all about waiving your rights rather than enforcing them and that might sound scary to the uninitiated... but better efforts toward educating them about free software may prove more productive than relying on a legal security blanket. Also as mentioned above, Gerrit does not enforce that the copyright holder has agreed to this, it only enforces that the person *uploading* the code into Gerrit has agreed to it... and section 7 of the ICLA has some interesting things to say about submitting third-party contributions, which looks to me like a permitted loophole for getting ASL code into the project without the author directly agreeing to a CLA at all. > > 7. Should You wish to submit work that is not Your original > > creation, You may submit it to the Project Manager separately > > from any Contribution, identifying the complete details of its > > source and of any license or other restriction (including, but > > not limited to, related patents, trademarks, and license > > agreements) of which you are personally aware, and conspicuously > > marking the work as "Submitted on behalf of a third-party: > > [named here]". I wonder if the current de facto practice of allowing git's author header to reflect the identity of the third-party counts as a conspicuous mark for the purposes of ICLA section 7? And whether submitting it to Gerrit where it can be openly inspected by the entire project counts as a submission to the Project Manager (the OpenStack Foundation) as well? At any rate, it seems that the agreement boils down to "copyright holders promise that they're contributing code under this license, or that they're submitting someone else's work who probably is okay with it." -- Jeremy Stanley

2 2

[Fwd: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)]
by Mark McLoughlin 22 Oct '13

22 Oct '13

Full thread here: http://lists.openstack.org/pipermail/openstack-dev/2013-October/thread.html… Mark. -------- Forwarded Message -------- > From: Thomas Goirand <zigo(a)debian.org> > Reply-to: OpenStack Development Mailing List > <openstack-dev(a)lists.openstack.org> > To: OpenStack Development Mailing List > <openstack-dev(a)lists.openstack.org> > Subject: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in > all OpenStack projects (and [trove] > python-troveclient_0.1.4-1_amd64.changes REJECTED) > Date: Sat, 19 Oct 2013 14:01:50 +0800 > > Hi there, > > TroveClient just got rejected by Debian FTP masters. Reply from Luke > Faraone is below. > > In general, I would strongly advise that a clean COPYRIGHT-HOLDER file > is created with the copyright holders in them. Why? Because it is hard > to distinguish between authors and copyright holders, which are very > distinct things. Listing the authors in debian/copyright doesn't seem to > satisfy the FTP masters as well... :( > > FYI, my reply was that I knew some of the authors were working for > Rackspace, because I met them in Portland, and that I knew Rackspace was > one of the copyright holders. Though that's of course not enough for the > Debian FTP masters. > > Your thoughts? > > Cheers, > > Thomas Goirand (zigo) > > -------- Original Message -------- > Subject: [Openstack-devel] python-troveclient_0.1.4-1_amd64.changes REJECTED > Date: Sat, 19 Oct 2013 04:00:19 +0000 > From: Luke Faraone <ftpmaster(a)ftp-master.debian.org> > To: PKG OpenStack <openstack-devel(a)lists.alioth.debian.org>, Thomas > Goirand <zigo(a)debian.org> > > > Dear maintainer, > > debian/copyright is **not** an AUTHORS list. This package appears to be > Copyright (c) 2013 Hewlett-Packard Development Company, L.P., and some > other > companies, not copyrighted each individual employee at HP who worked on it. > > Your automated debian/copyright generation is most probably suboptimal for > most packages, and is most certainly not a substitute for manual review. > One > missed copyright holder: > > python-troveclient-0.1.4\troveclient\base.py: > Copyright 2010 Jacob Kaplan-Moss > > Cheers, > > Luke Faraone > FTP Team > > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > > _______________________________________________ > Openstack-devel mailing list > Openstack-devel(a)lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/openstack-devel > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

6 11

Legal Concerns Over Project Names
by Mark McLoughlin 20 Jun '13

20 Jun '13

Hi, It's become pretty apparent that we need good guidance for people on this issue: https://wiki.openstack.org/wiki/LegalIssuesFAQ#Legal_Concerns_Over_Project_… I'm reluctant to attempt to draft any such guidance, but I assume it at least begins with "talk to the project's PTL privately and don't raise the issue on a public forum". Cheers, Mark.

3 4

[Fwd: [openstack-dev] [metrics] Code contribution by 3rd party consultant on behalf of a corporation]
by Mark McLoughlin 18 Jun '13

18 Jun '13

Folks on legal-discuss might have input on dealing with the CLA etc. Cheers, Mark. -------- Forwarded Message -------- > From: Chan, Winson C <winson.c.chan(a)intel.com> > Reply-to: OpenStack Development Mailing List > <openstack-dev(a)lists.openstack.org> > To: openstack-dev(a)lists.openstack.org > <openstack-dev(a)lists.openstack.org> > Subject: [openstack-dev] [metrics] Code contribution by 3rd party > consultant on behalf of a corporation > Date: Mon, 17 Jun 2013 20:33:08 +0000 > > Metrics team, > > > > Is there a best practice for counting commits made by a 3rd party > consultants/contractors (with multiple affiliations) on behalf of > another corporation? I recently had a conversation with Stefano and > he suggested adding a “Contributed for: <affiliation>” in the commit > message. Stefano recommended that I get the dialog started here… > > > > Thanks. > > Winson > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

[Fwd: [openstack-dev] How to handle forking of projects]
by Mark McLoughlin 06 Jun '13

06 Jun '13

Hey Please see the question below about a GPL licensed bundled javascript library in Horizon Cheers, Mark. -------- Forwarded Message -------- > From: Matthias Runge <mrunge(a)redhat.com> > Reply-to: OpenStack Development Mailing List > <openstack-dev(a)lists.openstack.org> > To: openstack-dev(a)lists.openstack.org > Subject: [openstack-dev] How to handle forking of projects > Date: Thu, 06 Jun 2013 10:34:41 +0200 > > Hey, > I came to this question over the the following review: > https://review.openstack.org/#/c/31725/ > > The situation is: Horizon ships a bundled library query-table-sorter, > which hasn't seen a release since ages. > The proposed commit changes the bundled lib, effectively creating a fork. > > Is that allowed/desired, or how should we handle this? > As a side note, that plugin is licensed as GPL (without a version) and MIT. > > Are we allowed to bundle this at all? > > Matthias > > _______________________________________________ > 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] [openstack-tc] Copyrights and License Headers in source files
by Mark Washenberger 21 May '13

21 May '13

> > This is really an education issue. Lots of first time Open Source folks on > the project that don't understand that copyright + license grant in each > file is actually quite important to ensure things are actually Open Source > in all jurisdictions. > This seems to be the detail I was missing. Can someone elaborate a bit about where this is a problem?

6 20