- legal-discuss - lists.openstack.org

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 19 Jun '13

19 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 17 Jun '13

17 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

AUTO: Joseph Bracken is out of the office. (returning 05/23/2013)
by Joseph Bracken 18 May '13

18 May '13

I am out of the office until 05/23/2013. I will respond to your email at the earliest opportunity after I return. For emergency pricing matters, see Tom Jones (tomj(a)us.ibm.com) For all other emergency matters, see Jeff Thompson (jthom(a)us.ibm.com) Note: This is an automated response to your message "legal-discuss Digest, Vol 2, Issue 11" sent on 05/18/2013 6:00:02 AM. This is the only notification you will receive while this person is away.

1 0

Re: [legal-discuss] [openstack-tc] Copyrights and License Headers in source files
by Mark Brown 15 May '13

15 May '13

On Tue, May 14, 2013 at 09:56:17AM -0700, Mark Washenberger wrote: > > Unless anyone has a stronger counterpoint to the view Richard has expressed > > here, I'd like to proceed with plans to stop allowing commits that add new > > copyright headers to new file additions in Glance (LICENSE file isan obvious > > exception). > > Just a clarification, I wasn't taking any position on the issue, but > rather countering what appeared to be a strongly-held position that > seemed to rest on some legal assumptions. > > There could be other reasons to favor placement of copyright notices > in each file. I see that y'all have talked about this back and forth a bit - and I agree that per-file copyright can contain some headaches. However, I have had some very *practical* experience in this area; I was at one time directly involved in a major lawsuit surrounding open source, copyright and licensing (see my email address & your first guess will probably be correct). In several cases, the provenance of individual files was being investigated, and per-file copyright statements were an important part of that. IANAL, but I heartily suggest that this topic be brought up at the Foundation level, before we put anything into effect at the Project level. Mark Brown

5 11

Copyright statements in _empty_ files
by David Ripton 15 May '13

15 May '13

I'm not generally advocating removing copyright statements from source files. If the author(s) put them in, then it's (at least) rude to take them out without permission, and getting permission from thousands of contributors would be a pain. But there's one particular case that drives me nuts. We have source code files that contain _only_ a copyright statement, and no actual content to assert copyright over. (I'm not talking about NOTICE files that exist to hold copyright statements; I'm talking about zero-byte __init__.py files that exist to mark a directory as a Python package.) You can't copyright a zero-byte file; there's no original creative content there. And, because the copyright blurb makes the file's size nonzero, people waste time reading it to look for code. Anyone object to me emptying source files that contain no code, just copyright statements and boilerplate vim/emacs comments? -- David Ripton Red Hat dripton(a)redhat.com

4 3