- legal-discuss - lists.openstack.org

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 20 Feb '14

20 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 11 Feb '14

11 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 23 Oct '13

23 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 22 May '13

22 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