- legal-discuss - lists.openstack.org

[administrivia] Recent change in moderation for new subscribers
by Jeremy Stanley 27 Mar '25

27 Mar '25

Due to a spammer subscribing to legal-discuss earlier today in order to send off-topic messages to the list, I've altered the default behavior for posts from new subscribers. For now, if someone subscribes, their initial post to the list will be held for moderation in order for our moderators to make sure it's a legitimate post, before setting their subscription to bypass moderation for any subsequent posts they make. Note that this only affects new subscriptions as of now, anyone who has already subscribed to the list before now should see no change in how things work for them. As for the spam to the list today, I've blocked that subscriber from sending any new messages and deleted their off-topic posts from the public archive. Please let me know if you have any questions. -- Jeremy Stanley

1 0

Apache license header in Puppet manifests
by Francesco Di Nucci 06 Mar '25

06 Mar '25

Hi all, the PR 943232 to puppet-horizon led to an interesting IRC discussion with Takashi and Tobias about the (not) usage of the Apache license header in Puppet manifests. Actually the OpenStack puppet-* modules have the LICENSE file and almost all the Puppet manifests do NOT have an header on top to state the license. On one hand Apache license help <https://www.apache.org/legal/apply-license.html#new> states that "Each original source document (code and documentation, but not the LICENSE and NOTICE files) should include a short license header at the top"; on the other hand a lot of Puppet modules on the Forge seems to not use it (including Puppetlabs' and Puppet's). Are we missing something in interpreting the license or should we add the license header on top of all files? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

3 4

We need the last modification date in the CoC
by Alvaro Soto 20 Nov '24

20 Nov '24

Hi all, I personally believe it'll be a good idea to have the last modification date in our CoC [1]. It's hard to know if has been modified and if we need to read it again to understand the changes. From my end, I need to have this information to translate the changes to my local community. [1] https://openinfra.dev/legal/code-of-conduct How can we work this out? Cheers.

2 2

[administrivia] Recent spam on this list
by Jeremy Stanley 09 Oct '24

09 Oct '24

A spammer subscribed and sent several messages to the list in the past few minutes. I've blocked them from sending any further messages and deleted the initial ones from the list archive. If the problem resurfaces with additional users, I'll switch the list to initially moderate new subscribers or even just set it fully moderated (this particular mailing list gets so little traffic that it wouldn't impede discussion that much anyway). -- Jeremy Stanley

1 0

LICENSE question - Openstack Masakari
by Michal Arbet 15 Aug '24

15 Aug '24

Hello, I would like to implement the option to use the OpenStack project Masakari together with HashiCorp Consul. Currently, Corosync is used, but it has a limitation of 32 hosts. However, my question is, if I develop a way to build the image (OpenStack project Kolla) and orchestration (OpenStack project Kolla-Ansible) of the Consul project as a necessary tool in connection with Masakari, is it possible to merge such code? I am asking because Consul is under the BSL 1.1 license and according to https://governance.openstack.org/tc/reference/licensing.html, such questions need to be consulted on this mailing list. Consul license https://github.com/hashicorp/consul/blob/main/LICENSE The BSL 1.1 text includes the sentence: "The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work. The Licensor may make an Additional Use Grant, above, permitting limited production use." and in the Consul License, this passage is defined as follows: Additional Use Grant: You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with HashiCorp's paid version(s) of the Licensed Work. For purposes of this license: Does this mean that it meets the requirements of OpenStack Governance? Even though it is not an OSI-approved license? Thank you very much Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

4 9

CoC translation to Spanish
by Alvaro Soto 07 Mar '24

07 Mar '24

Hi all, As part of being a more inclusive community, I started a translation process on the CoC using our GitHub repository[1], and with the LATAM community, we are managing to finish it[2]. However, we would like to get the approval so this can be official. From Allison's comments, I understand that the foundation doesn't have any Spanish-fluent employees. So, my question is: - How can we get this translation validated? - What will you need from us to do, so we can get this translation as official? 1- https://github.com/opensource-latinamerica/openinframx/issues/5 2- https://github.com/opensource-latinamerica/openinframx/blob/5-post-add-open… Cheers! -- Alvaro Soto *Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you.* ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people.

1 0

Outreachy applicant Harshita Verma
by 174_Harshita verma 08 Mar '23

08 Mar '23

To post to this mailing list. harshita174btcse21(a)igdtuw.ac.in

1 0

GPLv3 and Apache2 licences for Openstack repos
by Sergey Sh 09 Dec '19

09 Dec '19

Hi, all I wonder if I can get help here or suggestions for licenses question. We move Ansible modules from upstream Ansible repository to Openstack namespace. In parallel, we need to develop new modules and modules that will replace those moved from Ansible. Moved original modules won't change. The problem is that Ansible and its modules have GPLv3 license and repositories of Openstack have Apache2. There are about 150+ people committed to Ansible modules for years, so it's hardly possible to get approval for relicensing from everyone. How can we handle this situation without violating licenses and agreements? As I see it's 3 options 1. Move GPL modules to SIG repo in Openstack, freeze them there, and create a new Openstack repo with Apache2 license and develop the new modules in it. Won't it be a problem if new modules will have the same functionality as GPL ones? 2. Move GPL modules to SIG repo in Openstack, to develop new modules in GPL there. 3. Move GPL modules to SIG repo in Openstack, to develop new modules in Apache2 there. I think because of partial incompatibility of Apache2 <-> GPLv3 licenses option 3 is barely viable [1] Option 2 is less preferred because it puts module aside from all Openstack projects that have Apache2 license. What are the potential issues of option 1? I'd appreciate any ideas or opinions about the topic. Thanks [1] https://www.apache.org/licenses/GPL-compatibility.html *Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.* -- Best regards Sagi Shnaidman

3 2

Seeking approval for inclusion of Scapy in global-requirements
by Nate Johnston 24 Jul '19

24 Jul '19

OpenStack legal-discuss, Hello, my name is Nate Johnston and I work primarily on OpenStack neutron. I am currently working on a new feature to permit or restrict traffic based on ethertype. This is a change that has security implications, because it allows us to restrict certain types of network traffic that we have ignored until now - specifically ethertypes other than IPv4, IPv6 and ARP within an L2 broadcast domain. In order to properly test this functionality I needed to create packets with custom ethertypes and test their arrival or non-arrival. The best tool for this is the 'scapy' library, which is licensed GPL v2. This would be a testing-only usage, and would not be used at runtime, so per the Licensing Requirements page I am seeking approval from you. The requirements change where I have requested this is [1]; the homepage for the Scapy project is [2]. Thanks, Nate Johnston [1] https://review.opendev.org/#/c/671776/ [2] https://scapy.net/

2 1

Fwd: [OpenStack Foundation] OSF Product Classification Matrix
by Fred Li 21 May '19

21 May '19

Hope legal discussion team can help on this topic. Thanks ---------- Forwarded message --------- From: Mohammed Naser <mnaser(a)vexxhost.com> Date: Tue, May 21, 2019 at 7:30 PM Subject: Re: [OpenStack Foundation] OSF Product Classification Matrix To: Fred Li <yongle.li(a)gmail.com> Cc: <foundation(a)lists.openstack.org>, <foundation-board(a)lists.openstack.org> On Tue, May 21, 2019, 7:20 PM Fred Li <yongle.li(a)gmail.com> wrote: > > I am wondering whether projects under OpenStack Foundation follows US > Export Regulations[1] or not. I tried check OpenStack legal > documents[2], but didn't find anything about this topic. > As an example, ASF listed the ECCN (Export Control Classification > Number) for its software [3]. I don't know where I can find OpenStack > projects' ECCN. First off -- I'm sorry that this is even something you have to deal with right now. We should focus on ensuring that we maintain our four opens. http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss I suggest perhaps forwarding your email to the mailing list above. > Hope you can help to point the information. > > [1] http://www.bis.doc.gov/ > [2] https://www.openstack.org/legal/ > [3] https://www.apache.org/licenses/exports/ > > -- > Regards > Fred Li (李永乐) > > _______________________________________________ > Foundation mailing list > Foundation(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation -- Regards Fred Li (李永乐)

1 1

Re: [legal-discuss] [tc] OpenStack code and GPL libraries
by Jeremy Stanley 04 Feb '19

04 Feb '19

On 2019-02-04 14:42:04 +0100 (+0100), Ilya Shakhat wrote: > I am experimenting with automatic verification of code licenses of > OpenStack projects and see that one of Rally dependencies has GPL3 > license [...] To start off, it looks like the license for morph is already known to the Rally developers, based on the inline comment for it at https://git.openstack.org/cgit/openstack/rally/tree/requirements.txt?id=362… (so hopefully this is no real surprise). The source of truth for our licensing policies, as far as projects governed by the OpenStack Technical Committee are concerned (which openstack/rally is), can be found here: https://governance.openstack.org/tc/reference/licensing.html It has a carve out for "tools that are run with or on OpenStack projects only during validation or testing phases of development" which "may be licensed under any OSI-approved license" and since the README.rst for Rally states it's a "tool & framework that allows one to write simple plugins and combine them in complex tests scenarios that allows to perform all kinds of testing" it probably meets those criteria. As for concern that a Python application which imports another Python library at runtime inherits its license and so becomes derivative of that work, that has been the subject of much speculation. In particular, whether a Python import counts as "dynamic linking" in GPL 3.0 section 1 is debatable: https://bytes.com/topic/python/answers/41019-python-gpl https://opensource.stackexchange.com/questions/1487/how-does-the-gpls-linki… https://softwareengineering.stackexchange.com/questions/87446/using-a-gplv3… https://stackoverflow.com/questions/40492518/is-an-import-in-python-conside… I'm most definitely not a lawyer, but from what I've been able to piece together it's the combination of rally+morph which potentially becomes GPLv3-licensed when distributed, not the openstack/rally source code itself. This is really more of a topic for the legal-discuss mailing list, however, so I am cross-posting my reply there for completeness. To readers only of the legal-discuss ML, the original post can be found archived here: http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002356… -- Jeremy Stanley

1 0

On the problem of OSF copyright headers
by Jeremy Stanley 28 Aug '18

28 Aug '18

Just a heads up, the perennial topic of copyright assignment misconceptions has reared its head again. I've posted http://lists.openstack.org/pipermail/openstack-dev/2018-August/133929.html on the openstack-dev mailing list proposing that we should have somewhere more formal than a wiki article to put the summary for that. -- Jeremy Stanley

1 0

Third party file inclusion in Openstack sushy project
by mail＠clusums.eu 16 Aug '18

16 Aug '18

Hi, I'm working on sushy project[1] and I want to know if I can include some third-party files in the project and distribute the project together with these files. The files in question are JSON files here [2], for example, [3]. They do not have any license specified, but they have "Copyright 2014-2015, 2017 Distributed Management Task Force, Inc. (DMTF). All rights reserved.". This corresponds to full copyright notice at [4]. The questions: 1) Can I include these files in sushy project as they are? 2) If not, can I process these files automatically using a script and derive some code from these files and include the derived code in sushy project? 3) If not, can I process these files manually and type some code and include the derived code? 4) Is there something else? Regards, Aija [1] https://docs.openstack.org/sushy/latest/ [2] http://redfish.dmtf.org/schemas/registries/ [3] http://redfish.dmtf.org/schemas/registries/Base.1.2.0.json [4] https://www.dmtf.org/about/policies/copyright

5 19

Re: [legal-discuss] [openstack-dev] [tc] [all] TC Report 18-05
by Graham Hayes 30 Jan '18

30 Jan '18

On 30/01/18 18:34, Chris Dent wrote: <snip/> > > ## Today's Board Meeting > > I attended [today's Board > Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018Boa… > > but it seems that according to the [transparency > policy](http://www.openstack.org/legal/transparency-policy/) I can't > comment: > >> No commenting on Board meeting contents and decisions until >> Executive Director publishes a meeting summary > > That doesn't sound like transparency to me, but I assume there must be > reasons. I was under the assumption that this only applied to board members, but I am open to correction. Can someone on legal-discuss clarify? > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >

2 2

[tc][qa] possible license violation in os-faults project
by Pavlo Shchelokovskyy 23 Nov '17

23 Nov '17

Hi all, today I came about what I see as a possible violation of GPLv3 license in openstack/os-faults project. As all other openstack/* projects, openstack/os-faults and all of its code is licensed under Apache v2 license. But the code in os_faults/ansible/executor.py module explicitly imports multiple modules [0] from Ansible, which in turn are licensed under GPLv3 license (example of the first imported module [1]). IANAL, but as far as I understand Apache v2 and GPLv3 licenses are incompatible in this regard. I'd like to be proven wrong, but it seems this code in os-faults must be removed, and if needed rewritten to call out to "ansible" or "ansible-playbook" CLI scripts (and parsing their stdout) instead. [0] http://git.openstack.org/cgit/openstack/os-faults/tree/os_faults/ansible/ex… [1] https://github.com/ansible/ansible/blob/v2.4.1.0-1/lib/ansible/executor/tas… Best regards, -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com

3 2

[tc][kolla] Distribute Ansible module with Kolla
by duonghq＠vn.fujitsu.com 01 Aug '17

01 Aug '17

Hello everyone, I'm looking for legal advice about distribute Ansible module within Kolla. In order to implement one feature in Kolla, I need developing one Ansible strategy plugin, which in turn need to include and inherit from a couple of modules of Ansible. Kolla does not use the plugin directly, Kolla will invoke Ansible (through popen) and Ansible uses this plugin. The question is, can I distribute this plugin along with Kolla-Ansible deliverable? Thanks, Ha Quang Duong (Mr.) IRC duonghq PODC - Fujitsu Vietnam Ltd.

3 2

License issue & Need help
by HoangCX＠vn.fujitsu.com 26 Jul '17

26 Jul '17

Hi, We are recently trying to propose a Netlink solution [1] in order to improve performance for Neutron's Security Group. Almost the thing is ready to go except for license issue as we are not so familiar with this area. The problem is come from some parts of code we used that based on MIT license (not Apache 2 license). So need to get help for the following points: 1. Can we mix MIT license and Apache 2 license in a same file like [2]? 2. We have LICENSE file at the top directory. Is it okay to have a file with some different license under the tree and publish it as part of neutron distribution? Any feedback and help are really appreciated. [1] https://review.openstack.org/#/c/470911/ [2] https://review.openstack.org/#/c/470911/20/neutron/privileged/agent/linux/n… Thanks, Hoang

2 1

Hosting a non-official GPLv3 OpenStack project
by David Moreau Simard 25 Jul '17

25 Jul '17

Hi, I'm the author of ARA [1] which is not an official OpenStack project: - It is not governed by the OpenStack foundation or the technical committee - It does not require the OpenStack CLA/ICLA for contributions - It is not a deliverable of any OpenStack project For me, ARA falls in the same category of software that was created by the OpenStack community as Jenkins Job Builder [2] and git-review [3]. >From the licensing requirements documentation [4]: > Projects run as part of the OpenStack Infrastructure (in order to produce OpenStack software) may be licensed under any OSI-approved license. > This includes tools that are run with or on OpenStack projects only during validation or testing phases of development (e.g., a source code linter). It would likely fit in what was previously known as "stackforge". While ARA is currently labelled with an Apache 2.0 license, some components of it are coupled to Ansible which is GPLv3. For the purpose of simplicity and avoid headaches around dual licensing (worry about what we are importing where, etc.), I am currently considering re-licensing ARA as GPLv3. Doing this re-licensing now rather than later is desirable before ARA gets too many contributors from different companies which may complicate a re-licensing. My question is the following: Would this re-licensing mean that ARA could no longer be hosted by the OpenStack community infrastructure ? What are other ramifications I might be missing ? Thanks, [1]: https://gihtub.com/openstack/ara [2]: https://github.com/openstack-infra/jenkins-job-builder [3]: https://github.com/openstack-infra/git-review [4]: https://governance.openstack.org/tc/reference/licensing.html David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter]

3 2

GPLv2 dependency in puppet-neutron?
by ZZelle 11 Jul '17

11 Jul '17

Hi everyone, While working on puppet-neutron, i discovered that puppet-neutron depends on the sysctl puppet module[1] which is GPLv2 (be careful to not confuse it with another sysctl module[2] which is apache2). This dependency has been added a long time ago (in juno or before). It seems we have a license issue (ie: apache2 code depends on GPLv2 code)? [1] https://github.com/duritong/puppet-sysctl [2] https://github.com/thias/puppet-sysctl Cédric/ZZelle@IRC

2 1

[collectd-ceilometer-plugin][legal] Request to relicense collectd-ceilometer-plugin under MIT license.
by Foley, Emma L 09 Feb '17

09 Feb '17

Hi all, We have had a request from the OPNFV community to relicense the collectd-ceilometer-plugin [1] to prevent potential license conflicts. OPNFV [2] produces a set of ISOs which will include collectd [3] and collectd-ceilometer-plugin. Some collectd components are GPL v2 licensed, which would cause a conflict at the point of distribution, if both the GPL plugins and the collectd-ceilometer-plugin were enabled by default. The proposed solution is to change the license of collectd-ceilometer-plugin from Apache V2 to MIT. As far as I can see, this is appropriate and will maintain compatibility As a consequence of this change, all contributors need to agree to the change. I'm currently planning to propose a patch to change the license, and asking all the previous contributors to add a "signed-off-by" line to the commit message to show they consent to the change. Are there any issues with the proposed license change? Is the proposed method of getting consent suitable? Best regards, Emma [1] http://github.com/openstack/collectd-ceilometer-plugin.git [2] https://www.opnfv.org/ [3] https://collectd.org/ https://governance.openstack.org/tc/reference/licensing.html -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263

2 1

openstack CLA usage
by John Dickinson 31 Jan '17

31 Jan '17

Can the OpenStack CLA (https://review.openstack.org/static/cla.html) be used as a template for other projects (non-OpenStack)? Is there a "license" of the CLA itself? --John

2 1

Re: [legal-discuss] [kolla]is it OK to modify python code in OpenStack project?
by Jeffrey Zhang 03 Jan '17

03 Jan '17

Thanks all guys. Copy python code is really a bad idea. Now i have moved to re-use oslo.config iniparser[0][1], which works too. So we have no license issue, now. ;) [0] https://github.com/openstack/oslo.config/blob/master/oslo_config/iniparser.… [1] https://review.openstack.org/#/c/412101/5/ansible/action_plugins/merge_conf… On Tue, Jan 3, 2017 at 1:04 AM, Van Lindberg <van.lindberg(a)rackspace.com> wrote: > Thierry is correct in his analysis. > > > If you really want to copy it - which I don't suggest - then copy it over > into your repo, rename both the module and the class, and make your code > use your derived work. > > > Put a header at the top that says something like "Based on Python's > ConfigParser.py. Original ConfigParser.py distributed under the Python > Software Foundation license. Additions and changes copyright [YOU] and > distributed under the Apache Software License, v2." > > > Do not modify the stdlib in-place (as it sounds like you are doing) - but > perhaps I just misunderstand. > > > ------------------------------ > *From:* Thierry Carrez <thierry(a)openstack.org> > *Sent:* Monday, January 2, 2017 4:45 AM > *To:* legal-discuss(a)lists.openstack.org > *Subject:* Re: [legal-discuss] [kolla]is it OK to modify python code in > OpenStack project? > > Jeffrey Zhang wrote: > > Recently, Kolla project has requirement to modify[1] the python's > > ConfigParser.py code[0]. > > > > Python is using PSF license[3], which is GPL compatible. But OpenStack > > is using Apache License. > > > > Here is the diff view[2]. > > > > I want to make sure: is it OK to re-license ConfigParser.py? If not, what > > the solution? > > > > [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py > > [1] https://review.openstack.org/412101 > > [2] https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da3 > 71/revisions?diff=split > > [3] https://docs.python.org/3/license.html > > I'm not a lawyer, but it sounds slightly tricky. > > The PSF license is Apache-compatible, which means that you can combine > PSF-licensed and Apache-licensed code (if you retain the original > licenses). But OpenStack code must be licensed under a license supported > by the Contributor License Agreement (CLA) which allows redistribution > by the OpenStack Foundation under ASLv2 (currently only ASLv2, the MIT > and both forms of the BSD license meet this requirement). > > So I don't think we can really bundle PSF-licensed code within OpenStack > code, and I think too much was copied from the original class so that > anyone can pretend it is original work. > > Three solutions that should work around the problem without requiring > lawyers to further investigate the issue: > > 1/ Do a clean room implementation (by someone not familiar with the > original code) > > 2/ Rewrite your code so that it takes a pure ConfigParser class output > and transforms it into what you need, rather than copying code over > > 3/ Publish your modified ConfigParser into its own 3rd-party PyPI > library (licensed under the PSF license) > > Of those, (2) is the one that introduces the less technical debt (no > code copy). > > -- > Thierry Carrez (ttx) > > _______________________________________________ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me

1 0

[kolla]is it OK to modify python code in OpenStack project?
by Jeffrey Zhang 02 Jan '17

02 Jan '17

Recently, Kolla project has requirement to modify[1] the python's ConfigParser.py code[0]. Python is using PSF license[3], which is GPL compatible. But OpenStack is using Apache License. Here is the diff view[2]. I want to make sure: is it OK to re-license ConfigParser.py? If not, what the solution? [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py [1] https://review.openstack.org/412101 [2] https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da371/revision… [3] https://docs.python.org/3/license.html -- Regards, Jeffrey Zhang Blog: http://xcodest.me

3 2

Re: [legal-discuss] [all][tc][kolla]is it OK to modify python code in OpenStack project?
by Michał Jastrzębski 02 Jan '17

02 Jan '17

Added all and tc tags, as it might affect everyone really. On 25 December 2016 at 23:04, Jeffrey Zhang <zhang.lei.fly(a)gmail.com> wrote: > Recently, Kolla project has requirement to modify[1] the python's > ConfigParser.py code[0]. > > Python is using PSF license[3], which is GPL compatible. But OpenStack > is using Apache License. > > Here is the diff view[2]. > > I want to make sure: is it OK to re-license ConfigParser.py? If not, what > the solution? > > [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py > [1] https://review.openstack.org/412101 > [2] > https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da371/revision… > [3] https://docs.python.org/3/license.html > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > _______________________________________________ > legal-discuss mailing list > legal-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss >

4 3

Re: [legal-discuss] [all][tc][kolla]is it OK to modify python code in OpenStack project?
by Jeffrey Zhang 27 Dec '16

27 Dec '16

not simple override the _read() method. I also copied some code from ConfigParser.py(more than 80%, i think). is that OK? is there any difference between override method and copy codes? On Tue, Dec 27, 2016 at 3:12 AM, Monty Taylor <mordred(a)inaugust.com> wrote: > On 12/26/2016 07:27 AM, Davanum Srinivas wrote: > > PSF is ok per (https://governance.openstack.org/tc/reference/licensing. > html) > > Though the overriding the _read() seems like something that could > > break easily > > Yah - you can't relicense it - but you can include it with the PSF > license. It might be worth adding a PSF license header to that file and > a note that the code is copied from [0] > > That said - I agree with dims, overriding the _read() method like that > seems prone to sadness. > > > On Mon, Dec 26, 2016 at 12:13 PM, Michał Jastrzębski <inc007(a)gmail.com> > wrote: > >> Added all and tc tags, as it might affect everyone really. > >> > >> On 25 December 2016 at 23:04, Jeffrey Zhang <zhang.lei.fly(a)gmail.com> > wrote: > >>> Recently, Kolla project has requirement to modify[1] the python's > >>> ConfigParser.py code[0]. > >>> > >>> Python is using PSF license[3], which is GPL compatible. But OpenStack > >>> is using Apache License. > >>> > >>> Here is the diff view[2]. > >>> > >>> I want to make sure: is it OK to re-license ConfigParser.py? If not, > what > >>> the solution? > >>> > >>> [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py > >>> [1] https://review.openstack.org/412101 > >>> [2] > >>> https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da3 > 71/revisions?diff=split > >>> [3] https://docs.python.org/3/license.html > >>> > >>> > >>> -- > >>> Regards, > >>> Jeffrey Zhang > >>> Blog: http://xcodest.me > >>> > >>> _______________________________________________ > >>> 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 > > > > > > > > > _______________________________________________ > legal-discuss mailing list > legal-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > -- Regards, Jeffrey Zhang Blog: http://xcodest.me

1 0

AGPLv3+ acceptable for third party dependencies?
by Ade Lee 11 Nov '16

11 Nov '16

Hi, Just a quick question: Is AGPLv3+ an acceptable license for a third party library that is a dependency for an Openstack project? I read: (from http://governance.openstack.org/reference/licensing.html) In order to be acceptable as dependencies of OpenStack projects, external libraries (produced and published by 3rd-party developers) must be licensed under an OSI-approved license that does not restrict distribution of the consuming project. The list of acceptable licenses includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL. Licenses considered incompatible with this requirement include GPLv2, GPLv3, and AGPL. Is AGPL the same as AGPLv3 (and therefore not acceptable)? Thanks, Ade Lee

5 7

[tc][kolla] Ansible module with GPLv3
by Michał Jastrzębski 07 Nov '16

07 Nov '16

Cross-post from [1] Hello everyone, I'm looking for legal advice about having GPLv3 file in Kolla repository. Our use case doesn't seem to be derivative, so I think that should be possible to pull off - having an single gpl v3 module within Kolla without affecting general Kolla license, but it's highly unorthodox so I would like to have second opinion on that front. Regards, Michal inc0 Jastrzebski [1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106761.html

3 4

Adding license header to autogenerated content
by Steve Martinelli 22 Oct '16

22 Oct '16

I recently came across a patch [1] that is trying to add the Apache license to an autogenerated file. We've recently had issues with contributors finding patches that apply to all the projects; this would definitely be one of those. My quick search [2] is showing that around 350 repositories have the license in the file. Out of the 1000+ we have in openstack (not including what's in openstack-infra or openstack-dev) Yes, it's a python file, there is some "code" there, but it's auto-generated, either from sphinx or our cookiecutter (which now includes the license [3]). So before we use up resources in merging a bunch of patches, I wanted to know if the license was actually necessary. Thanks for reading, Steve [1] https://review.openstack.org/#/c/377170/1 [2] http://codesearch.openstack.org/?q=Apache&i=nope&files=doc%2Fsource%2Fconf.… [3] https://github.com/openstack-dev/cookiecutter/blob/master/%7B%7Bcookiecutte…

4 6

Question on the ICLA
by Michael Latchmansingh 19 Oct '16

19 Oct '16

Hi OpenStack legal community I have a question on the purpose of the ICLA. In attempting to setup my local Git repository with the OpenStack Gerrit system, I ran into an issue where I was asked to sign the ICLA. My submissions to OpenStack are on behalf of the company I work for, and we have already a signed CCLA. Our general counsel does not want me to sign an individual CLA because I do not own any of the IP being submitted. Can you clarify, in legal terms for my general counsel, why there is this requirement? Thanks and Regards, Michael Latchmansingh | Director, Product Development 954-377-6058 t 561-927-5754 c michael.latchmansingh.datacore (skype) DataCore Software Corporation Corporate Park 6300 NW 5th Way Ft. Lauderdale, FL 33309 http://www.datacore.com<http://www.datacore.com/>

7 6

Trademark for a specific OpenStack project
by Davanum Srinivas 18 Oct '16

18 Oct '16

Hi, Does the foundation hold trademarks for any of the big tent projects? Does the policy cover any such marks? [1] What are the options if someone active in the community decides to continue their work outside the foundation using the same project name? Thanks, Dims [1] http://www.openstack.org/brand/openstack-trademark-policy/ -- Davanum Srinivas :: https://twitter.com/dims

2 2

Legal Affairs Committee Meeting, September 30, 1:15 PDT
by Strottman, Nissa 22 Sep '16

22 Sep '16

Hi- The Legal Affairs Committee will be meeting Friday, September 30, at 1:15 PDT to discuss Facebook's additional patent license grant in addition to the BSD license for ReactJS, which is being used in at least two projects (Fuel-UI and TripleO). The text for the patent grant may be viewed here: https://github.com/facebook/react/blob/master/PATENTS Call-in number: 1-702-696-4520 Passcode: 7612918876 Best, Nissa Nissa M. Strottman Associate General Counsel Software, Cloud and Open Source Office of the General Counsel +1 650 857 6279 Office +1 650 387 4987 Mobile Palo Alto, CA hpe.com [HPE logo]<http://www.hpe.com/>

1 0

Docker Inc. trademark guidelines
by Steven Dake (stdake) 19 Sep '16

19 Sep '16

It has come to my attention that Docker Inc has published trademark guidelines. The OpenStack Kolla community wishes to comply with the trademark guidelines Docker has published. I humbly request a legal review of the following change from a foundation attorney: https://review.openstack.org/#/c/372133/ Note the term “website” in the published guidelines could be parsed in multiple ways which I find confusing. Some guidance here would be helpful as well. (CCs are self-nominated PTLs for the Ocata cycle). Regards -steve

2 1

Technical Committee Member Policy - possible error?
by John Davidge 13 Sep '16

13 Sep '16

Hello, I happened to be reading the Technical Committee Member Policy[1] today, and I noticed what I think could be an error. Paragraph 3, subsection (b)(I) states that: "An Individual Member is an ATC who has had a contribution approved for inclusion..." I believe this should read: "An ATC is an Individual Member who has had a contribution approved for inclusion..." Generally speaking, ATCs are a subset of Individual Members, so the definition given doesn't seem right. Approved contributions are not a requirement for Individual Membership. Can anybody confirm? Thanks, John [1] http://www.openstack.org/legal/technical-committee-member-policy/ ________________________________ Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse(a)rackspace.com and delete the original message. Your cooperation is appreciated.

3 2

Re: [legal-discuss] [openstack-dev] [javascript] [fuel-ui] Is ReactJS OSI Compliant?
by Monty Taylor 11 Sep '16

11 Sep '16

Hey legal discuss folks ... On 09/07/2016 07:06 AM, Michael Krotscheck wrote: > Preface: IANAL (I-am-not-a-lawyer). > > ReactJS claims to be BSD licensed. However, it has a non-BSD patent > rider with a very aggressive "Strong Retaliation Clause", meaning that > if there's ever a patent dispute between [React Project] and Facebook, > the patents are revoked. > > This might be fine. It might not. If possible, I'd like one of the > foundation lawyers to weigh in on this, as one of our projects (Fuel-UI) > is using it. > > Some discussion on the matter: > https://news.ycombinator.com/item?id=12108158 > > Our own guidelines. > http://governance.openstack.org/reference/licensing.html > > Historically, OpenStack has avoided projects that make custom > modifications to a license (see the do-no-evil license on JSLint/JSHint). > > Michael > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >

3 2

Fwd: [openstack-dev] [javascript] [fuel-ui] Is ReactJS OSI Compliant?
by Davanum Srinivas 07 Sep '16

07 Sep '16

Fwd'ing to legal-discuss from openstack-dev ---------- Forwarded message ---------- From: Michael Krotscheck <krotscheck(a)gmail.com> Date: Wed, Sep 7, 2016 at 8:06 AM Subject: [openstack-dev] [javascript] [fuel-ui] Is ReactJS OSI Compliant? To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev(a)lists.openstack.org> Preface: IANAL (I-am-not-a-lawyer). ReactJS claims to be BSD licensed. However, it has a non-BSD patent rider with a very aggressive "Strong Retaliation Clause", meaning that if there's ever a patent dispute between [React Project] and Facebook, the patents are revoked. This might be fine. It might not. If possible, I'd like one of the foundation lawyers to weigh in on this, as one of our projects (Fuel-UI) is using it. Some discussion on the matter: https://news.ycombinator.com/item?id=12108158 Our own guidelines. http://governance.openstack.org/reference/licensing.html Historically, OpenStack has avoided projects that make custom modifications to a license (see the do-no-evil license on JSLint/JSHint). Michael __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims

1 0

Re: [legal-discuss] retention policy for old docs [WAS: [OpenStack-docs] Change of doc publishing]
by Lana Brindley 29 Aug '16

29 Aug '16

On 29/08/16 10:32, Lana Brindley wrote: > Hi everyone, > > Docs is planning some infrastructure changes, which would mean we need to consider our retention policy for old documentation on developer.openstack.org and docs.openstack.org. In the course of the discussion (some relevant bits below), we considered it prudent to ask the legal team to find out if Foundation have a retention policy in place for documentation on these sites that we should be aware of. > > Do you know of anything that might be relevant here? > > Thanks, > Lana > > > -------- Forwarded Message -------- > Subject: Re: [OpenStack-docs] Change of doc publishing > Date: Fri, 26 Aug 2016 17:36:53 -0700 > From: Anne Gentle <annegentle(a)justwriteclick.com> > To: Jeremy Stanley <fungi(a)yuggoth.org> > CC: openstack-docs(a)lists.openstack.org <openstack-docs(a)lists.openstack.org> > > > > > > On Fri, Aug 26, 2016 at 10:41 AM, Jeremy Stanley <fungi(a)yuggoth.org <mailto:fungi@yuggoth.org>> wrote: > > On 2016-08-26 05:40:31 -0700 (-0700), Anne Gentle wrote: > [...] > > I'd be comfortable with an archive policy that keeps all documents > > (project repos, openstack-manuals, api-site) for two years and > > then backs them up to a storage area that is not accessible from > > the web. > > Probably the closest thing we have to this is our server backups > (implemented using software called "bup"). Their purpose is to be > able to restore the previous state of our important systems in the > event of loss or compromise of service, so possibly not the same > thing you're desiring here. Also, identifying which documents are > "older" than a certain date is nontrivial (we can delete files last > modified before a certain date, but does that actually achieve the > same result?). > > How about taking this from the revision control perspective... we > (presumably) have the source used to build that rendered form of the > documentation all the way back to the beginning, and if someone > really needs (for legal reasons) a copy of it then they can expend > the resources to figure out how to render it again? > > > Lana, I believe you should review that with legal and the Foundation. > > There's the legal-discuss mailing list to get that started. > [...] > > [I am not a lawyer and I'm responding as a concerned member of the > community, not representing the opinions of my employer.] > > I won't object to anyone consulting lawyers, but I'm pretty sure the > Foundation (the only legal entity we really have in this context) is > under no contractual obligation to maintain documentation at all for > software produced by the community. It's probably best to start out > asking them from that angle, rather than soliciting their opinions > on how long they think old releases of software should have rendered > documentation on a Web site (that latter question is something the > community and in particular the community members working on that > content and those systems should be free to decide). > > I can understand the sort of legal paranoia which infects business > uses for documentation, but meeting those requirements falls on > those businesses. For example, Rackspace almost certainly retains > old versions of any documentation they've produced and published on > their site, some of which may be derived from old versions of > OpenStack upstream documentation, but meeting their document > retention requirements is not the legal responsibility of the > OpenStack community at large (how would any court even be able to > enforce such a requirement on our community itself?). > > > This phrasing is a bit strong (paranoia, infection, yikes). I want to be sure to represent that this is clearly an entirely new context, and all I have to draw from is past experiences. We'll need to listen to various representatives in the community to decide what outcomes we want here. > > > > If the OpenStack Foundation really is somehow legally responsible > for keeping and publishing old copies of OpenStack software > documentation, that's something they would need to do directly as > well. They have no authority to impose those requirements on the > community, and to my knowledge not even any mechanisms in place > through which they could ensure it's happening anyway. > > > Okay, this separation of Foundation from infra-team-members helps me understand your perspective in this policy shaping. > > I also want to add that this type of project is a cool opportunity to innovate in docs publishing. You'd learn a ton by helping out, and Andreas is a fantastic teacher, plus the infra team is super lively. At a scale of hundreds of thousands of pages this type of work is crucial, cool, and at a scale that you can have bragging rights on for years to come. :) > > Anne > > > -- > Jeremy Stanley > > _______________________________________________ > OpenStack-docs mailing list > OpenStack-docs(a)lists.openstack.org <mailto:OpenStack-docs@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs> > > > > -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com

1 0

license issue with barbican
by Thomas Bechtold 29 Jul '16

29 Jul '16

Hi, Barbican has a plugin called dogtag[1]. This plugin imports "pki". While I tried to add pki as an extras requirement[2] I realized that it's dogtag-pki[3] that is required and not pki[4]. Using pki leads to an import error because there is code from dogtag-pki needed that is not in pki. So I started to look into dogtag-pki and wanted to add it to the global requirements repository but while doing that I realized that dogtag-pki's license is GPLv2. And according to[5] this is incompatible. How to handle this? Should the dogtag plugin be removed from barbican's source tree? Best, Tom [1] http://git.openstack.org/cgit/openstack/barbican/tree/barbican/plugin/dogta… [2] https://review.openstack.org/#/c/344232/ [3] https://pypi.python.org/pypi/dogtag-pki [4] https://pypi.python.org/pypi/pki [5] http://governance.openstack.org/reference/licensing.html

2 1

[keystone][murano][trove][imm] Changing OpenStack LLC to OpenStack Foundation
by Amrith Kumar 25 Jul '16

25 Jul '16

Bug 1214176 seeks to "Fix copyright headers to be compliant with Foundation policies" and one of the changes being made is to substitute "OpenStack Foundation" in places where the code said "OpenStack LLC". Someone just pushed changes to Keystone, Murano and Trove today and I have some concerns about this change. Consider the following changes, [2], [3], [4], and [5]. They assert a copyright in 2011 or 2010 of an entity called "OpenStack Foundation" that was only established in 2012 [6]. Are these changes legally accurate? -amrith [1] https://bugs.launchpad.net/bugs/1214176 [2] https://review.openstack.org/#/c/346675/1/keystone/policy/backends/rules.py [3] https://review.openstack.org/#/c/346673/1/tools/install_venv.py [4] https://review.openstack.org/#/c/346669/1/murano/common/cf_config.py [5] https://review.openstack.org/#/c/346669/1/murano/common/config.py [6] http://www.businesswire.com/news/home/20120919005997/en/OpenStack-Launches-…

4 3

Re: [legal-discuss] [openstack-dev] [keystone][murano][trove][imm] Changing OpenStack LLC to OpenStack Foundation
by Amrith Kumar 25 Jul '16

25 Jul '16

Dinesh, With the required disclaimer that I'm not a lawyer, and I don't play one on TV, I believe that the changes proposed to Trove in [1] do not make sense. I am not, I do not believe, competent to answer the question of whether or not the earlier changes to cinderclient or ironic must be reverted. -amrith [1] https://review.openstack.org/#/c/346673/ > -----Original Message----- > From: Bhor, Dinesh [mailto:Dinesh.Bhor@nttdata.com] > Sent: Monday, July 25, 2016 8:44 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev(a)lists.openstack.org> > Subject: Re: [openstack-dev] [keystone][murano][trove][imm] Changing > OpenStack LLC to OpenStack Foundation > > Hi amrith, > > I can see the patches got merged against that bug with similar changes: > > [python-cinderclient] > https://review.openstack.org/#/c/47453/2/cinderclient/base.py > [ironic] > https://review.openstack.org/#/c/47451/2/ironic/common/image_service.py > > Do you think these changes needs to be reverted ? > > Thank you, > Dinesh Bhor > > -----Original Message----- > From: Amrith Kumar [mailto:amrith@tesora.com] > Sent: Monday, July 25, 2016 4:30 PM > To: legal-discuss(a)lists.openstack.org > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [keystone][murano][trove][imm] Changing OpenStack > LLC to OpenStack Foundation > > Bug 1214176 seeks to "Fix copyright headers to be compliant with > Foundation policies" and one of the changes being made is to substitute > "OpenStack Foundation" in places where the code said "OpenStack LLC". > > Someone just pushed changes to Keystone, Murano and Trove today and I have > some concerns about this change. > > Consider the following changes, [2], [3], [4], and [5]. > > They assert a copyright in 2011 or 2010 of an entity called "OpenStack > Foundation" that was only established in 2012 [6]. > > Are these changes legally accurate? > > -amrith > > [1] https://bugs.launchpad.net/bugs/1214176 > [2] > https://review.openstack.org/#/c/346675/1/keystone/policy/backends/rules.p > y > [3] https://review.openstack.org/#/c/346673/1/tools/install_venv.py > [4] https://review.openstack.org/#/c/346669/1/murano/common/cf_config.py > [5] https://review.openstack.org/#/c/346669/1/murano/common/config.py > [6] http://www.businesswire.com/news/home/20120919005997/en/OpenStack- > Launches-Independent-Foundation-Begins-Work-Protecting > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ______________________________________________________________________ > Disclaimer: This email and any attachments are sent in strictest > confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then > delete > and destroy this email and any attachments without any further use, > copying > or forwarding. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

Fwd: [tc][ansible][ironic] Reusing Ansible code in OpenStack projects
by Pavlo Shchelokovskyy 19 May '16

19 May '16

Hi all, I have a question re FOSS licenses interplay. I am pretty sure that OpenStack community (e.g. openstack-ansible) has already faced such questions and I would really appreciate any advice. We are developing a new ansible-based deployment driver for Ironic [0] and would like to use some parts of ansible-lib Python API to avoid boilerplate code in custom Ansible modules and callbacks we are writing, and in the future probably use Ansible Python API to launch playbooks themselves. The problem is Ansible and ansible-lib in particular are licensed under GPL v3 [1] "or later" [2]. According to [3] Apache 2.0 license is only one way compatible with GPL v3 (GPL v3-licensed code can include Apache 2.0-licensed code, but not vice versa). I am by far not a legal expert, so my questions are: Does it mean that the moment I do "from ansible import ..." in my Python code, which AFAIU means I am "linking" to it, I am required to use a GPLv3-compliant license for my code too (in particular not Apache 2.0)? What problems might that imply in respect with including such code in an OpenStack project (e.g. submitting it to Ironic repo) and distributing the project? If there are indeed problems with that, would it be safer to keep the code in a separate project and also distribute it separately? Even when distributed separately, will merely using (dynamically importing at run-time) a GPLv3-licensed driver from ApacheV2-licensed Ironic constitute any license violation? Note that technically we could avoid re-using Ansible code for Ansible modules and callbacks, just that it would be much-much less convenient. [0] https://review.openstack.org/#/q/topic:bug/1526308 [1] https://github.com/ansible/ansible/blob/devel/COPYING [2] https://github.com/ansible/ansible/blob/devel/lib/ansible/__init__.py#L8 [3] http://www.apache.org/licenses/GPL-compatibility.html Best regards, Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com

4 3

[keystone] ldappool - using MPL licensed code in-tree
by Steve Martinelli 12 May '16

12 May '16

A bit of background: - In order to make keystone py3 compatible, we have to make our LDAP code compatible - We use two libraries for our LDAP code: python-ldap and ldappool, both are not actively maintained - python-ldap has a py3 port called pyldap. Great! - ldappool does not have a py3 port. With all that said, ldappool is only a few hundred lines of code. Can we pull it in-tree? It looks like ldappool is MPL licensed: Version: MPL 1.1/GPL 2.0/LGPL 2.1 Exact license for ldappool is here: https://github.com/mozilla-services/ldappool/blob/master/ldappool/__init__.… We have a patch that pulls it in tree up for review (with a few changes to make it py3 friendly): https://review.openstack.org/#/c/311827/3/keystone/common/ldap/ldappool.py stevemar

1 1

Licensing for specs repos
by Ben Swartzlander 09 May '16

09 May '16

I started a thread [1] on the dev mailing list but wasn't able to get any helpful answers... The Manila project is creating a new repo for specs, and while looking at what other projects have done for specs repos, I could not figure out which license was being used. It seems that most specs repos (nova, cinder, neutron, contain a mixture of Apache 2.0 licensed stuff and CCBY (Creative Commons) licensed stuff. Some of these repos contain apparently-conflicting license declarations, with CCBY specified in the LICENSE file, but Apache 2.0 specified in the setup.cfg file. In all cases, individual files contain their own license declarations at the top and all of these repos contain some clearly Apache 2.0 licensed files (the python code in the repo) and some CCBY licensed files (the specs themselves). It seems unavoidable that we will have a similar situation in Manila, so I'm trying to figure out what to do at the top level for the LICENSE file and what license to point to in setup.cfg. Is there a way to explain to users that the project contains a mixture of 2 licenses? Is that acceptable or desirable? -Ben Swartzlander Manila PTL [1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/094065.html

2 1

legal affairs committee meeting
by Strottman, Nissa 05 Oct '15

05 Oct '15

The next legal affairs committee meeting will be held Wednesday, October 14 at 4 pm ET/1 pm PT. Join online meeting<https://join.houston.hp.com/meet/nissa.strottman/BQCH66WT> https://join.houston.hp.com/meet/nissa.strottman/BQCH66WT Join by Phone +1-978-289-4114 (USA, Andover, MA) +1-678-367-0003 (USA, Atlanta, GA) +1-512-865-6123 (USA, Austin, TX) +1-208-629-2920 (USA, Boise, ID) +1-970-672-4888 (USA, Fort Collins. CO) +1-281-377-1991 (USA, Houston, TX) +1-650-300-4050 (USA, Palo Alto, CA) 1-855-493-4983 (USA/ Canada HP Customers/Partners) Find a local number<https://join.houston.hp.com/dialin> Conference ID: 437192273 Nissa M. Strottman Software, Cloud and Open Source Office of the General Counsel nissa.strottman(a)hp.com<mailto:nissa.strottman@hp.com> T +1 650 857 6279 M +1 650 387 4987 F +1 650 857 5409 Hewlett-Packard Company 3000 Hanover Street MS 1601 Palo Alto, CA 94304-1112 USA [HP]<http://www.hp.com/>

1 0

Center for Internet Security hardening standards
by Major Hayden 17 Sep '15

17 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello there, I'm currently working on a security hardening spec[1] and blueprint[2] for openstack-ansible. The goal is to bring additional security to OpenStack hosts via openstack-ansible and also to help organizations down the path to various compliance programs (like PCI). One of the firm PCI requirements[2] is PCI DSS Requirement 2.2 (page 30 in the PDF) which states that organizations must adhere to "industry-accepted" hardening standards. A few examples include Center for Internet Security (CIS), ISO, SANS, and NIST. Most of these are geared towards deployments of Red Hat Enterprise Linux and Windows, not Ubuntu. CIS seems to have the most comprehensive security hardening standards available for Ubuntu, and I'm able to port many of their recommendations for RHEL-based systems over to Ubuntu systems. However, their terms of use appears to be fairly strict. Rackspace (my employer) is a CIS member, but the OpenStack Foundation is not (as far as I know). I've reached out to CIS' member services group via our Rackspace account to find out if there's a possibility to license these hardening standards for open source use with OpenStack projects, but I'm not sure who they should get in contact with on the OpenStack side to discuss it. Would anyone be able to advise me on how to proceed? Thanks a bunch! [1] https://review.openstack.org/#/c/222619/ [2] https://blueprints.launchpad.net/openstack-ansible/+spec/security-hardening [3] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf [4] https://benchmarks.cisecurity.org/downloads/form/index.cfm - -- Major Hayden -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV+sIhAAoJEHNwUeDBAR+xlqEQAJWZV23yNWV7+XN1Pm7Utb6R D+pwPfN9up7RMhK5OFzvRGSEaGiQPRop+ENKNeBfiRfLCkI6mx2w5Z58E5NQCJEs v4ddxY5LokzOpizDmFl2Dkq3mrPCyC6bAE1tml5KF80vM5Vkt2IHnt7w5Q9QQ4hF UOcKI/4DFB2USO5lQr8jUMILzBUHLB+QO9L4NVxvYiz6LS1xgDRQ7AbmdloldLZb UqbqZ4rswfpSwCMn+h2jpBDwVzIykg22jdYQY61as8I1i7HrZoXBF2TaSyGc4lca FAzMxYBF7swWQ+W+/uk8+SUYOgqVSqslHtDyxKbz03JPlMhkSgAVAF80Q0AGE3Yt eq85QdLHkJnpdZNEfQ/TQHki+2seL+UNM/iSHlx//M+Qa5AZdgk+noEOhGT/dH3I +Bmz/PGBLJM67oow82No28tEo05xVtIGgDt5bUVf0oWCYy0OHjaLJ8w0DBrKXXlX otKsn5Q0Z08WUreX7fL74snb2yhg0BsGuR/NsHkJ2YQbG67v4Cr1QhCL8UAyI+OU MIRG1eswdERZKpBzBO6d+h4GsfEo7fDB6Q0uHe9kiwzVq5gHCI3t/miYwz4vabYR uZ4YVnfNfAmbjhh5I/uSAf2ie4T9h2b+yoqG6Yn51p43aLuZEHcPmc1VVv7M50Dz KDQ5nkxc/3XQcnmrZV7j =u4SR -----END PGP SIGNATURE-----

1 0

Incorporating MIT licensed code
by Major Hayden 08 Sep '15

08 Sep '15

Hello there, I just reviewed the Legal Issues FAQ[1], but I have some more specific questions around adding MIT licensed code to an OpenStack project that has traditionally been Apache licensed. I've already ensured that the file in question has the appropriate header and copyright details, but I'm unsure about how to handle the root LICENSE file within the repository. The FAQ mentions: > Probably the easiest thing to do when incorporating BSD or MIT licensed code is to copy the copyright/license header from the source file into the destination file, as well as copying the copyright notice, license and disclaimer into the toplevel LICENSE file with a brief explanation of which code is under that license. Should I put a divider in the LICENSE file and paste in the MIT license details after that? This may be a silly question (please let me know if it is), but I wanted to make sure I was following the legal instructions very carefully. Thank you! [1] https://wiki.openstack.org/wiki/LegalIssuesFAQ -- Major Hayden

2 2

Legal Affairs Committee Follow Up
by Radcliffe, Mark 27 Jul '15

27 Jul '15

At the last meeting, I stated that I was not aware of any litigation to enforce the Apache Software License. I have done a Westlaw search and have confirmed that there have been no reported cases to enforce the Apache Software License. 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.

1 0

Licensing options for new project (Kolla) entering big tent
by Steven Dake (stdake) 10 Jul '15

10 Jul '15

Hi folks, Kolla is a project for OpenStack with the mission [1]: " Kolla provides production-ready containers and deployment tools for operating OpenStack clouds that are scalable, fast, reliable, and upgradable using community best practices. " We use a set of libraries only available in Ansible v2.0. Shade [2] ASL2.0 uses these Ansible python libraries [3] licensed under a GPLv3 license. We use Shade in Kolla directly. We had planned to fork these libraries in [3] and cherry-pick only the modules we really need until Ansible 2.0 is available. I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-projects-… To which Robert Collins suggested I speak with legal-discuss in this thread [4]. “ As I understand our current license situation, you won't be eligible for big-tent if you depend on GPLv3 code. >From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed " So I'm also strongly inclined to recommend you speak to the legal list about the implications here. Using a GPLv3 tool via the CLI is very different (by the GPL's design) to using it as a library. -Rob -- Robert Collins <rbtcollins(a)hp.com<mailto:rbtcollins@hp.com>> Distinguished Technologist HP Converged Cloud “ I’d really like a solution that doesn’t involve rewriting all of the Ansible modules from scratch in a different license, but I guess we can do that if necessary. Can the OpenStack legal team provide some guidance for future TC voting around the thread in [4]? Our deadline for this work is July 31, but we need several weeks to make adjustments to our plans, so if appropriate guidance for the Technical Committee (and our community project) could be offered soon, it would be much appreciated. Regards, -steve [1] https://wiki.openstack.org/wiki/Kolla [2] https://github.com/openstack-infra/shade [3] https://github.com/ansible/ansible-modules-core The thread: [4] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068612.html

7 16

Trademark policy page bug report: missing logos
by Dolph Mathews 11 Jun '15

11 Jun '15

(There might be a more appropriate place to send this note, such as a launchpad project or an email.address(a)openstack.org, but I could not find it. I trust that someone here can direct this to the right person!) In reading the OpenStack trademark policy [1], there are three occurrences of the phrase "shown immediately below" which imply that logos are intended to be included within the document, but no logos are included at all (or attempted to be included, according to the HTML source). [1] http://www.openstack.org/brand/openstack-trademark-policy/ -Dolph

2 2

StackForge and IP.
by Joe Marshall (projectcalico.org) 07 May '15

07 May '15

Hello, Following a suggestion from Jeremy Stanley (below), I'm contacting this list. If I understand Jeremy correctly, checking code in to StackForge does not transfer any IP, or grant any rights, other than those granted in the license declaration that we make in our code (in this case, the Apache 2.0 license). Is that correct? Many thanks, Joe Marshall. -----Original Message----- From: Emma Gordon Sent: 06 May 2015 13:06 To: Joe Marshall Subject: FW: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code? -----Original Message----- From: Jeremy Stanley [mailto:fungi@yuggoth.org] Sent: 06 May 2015 12:58 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code? On 2015-05-06 11:02:42 +0000 (+0000), Emma Gordon (projectcalico.org) wrote: > If fuel plugin code is checked into a stackforge repository (as > suggested in the fuel plugin wiki > https://wiki.openstack.org/wiki/Fuel/Plugins#Repo) who owns that > code? I am not a lawyer, but my understanding is that the individual copyright holders mentioned in comments at the tops of various files, listed in an AUTHORS file (if included) and indicated within the repository's Git commit history retain rights over their contributions in a project relying on the Apache License (or those rights may belong to their individual respective employers in a work-for-hire situation as well). > Is there a contributor license agreement to sign? (For example, > contributors to OpenStack would sign this > https://review.openstack.org/static/cla.html) If Fuel is planning to apply for inclusion in OpenStack, then it may make sense to get all current and former contributors to its source repositories to agree to the OpenStack Individual Contributor License Agreement. Note that it does _not_ change the ownership of the software (copyrights), it's intended to simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally. More detailed questions are probably best posed to the legal-discuss(a)lists.openstack.org<mailto:legal-discuss@lists.openstack.org> mailing list, or to your own private legal representation. -- Jeremy Stanley

5 7

Legal Affairs Committee meeting
by Strottman, Nissa 01 May '15

01 May '15

Hi- The next meeting of the OpenStack Legal Affairs Committee meeting will be held Wednesday, May 6, 2015, at 1 p.m. PT. Dial-in information, etc., is below. Please let me know if you have any questions . Best, Nissa Join online meeting<https://join.houston.hp.com/meet/nissa.strottman/BQCH66WT> https://join.houston.hp.com/meet/nissa.strottman/BQCH66WT Join by Phone +1-978-289-4114 (USA, Andover, MA) +1-678-367-0003 (USA, Atlanta, GA) +1-512-865-6123 (USA, Austin, TX) +1-208-629-2920 (USA, Boise, ID) +1-970-672-4888 (USA, Fort Collins. CO) +1-281-377-1991 (USA, Houston, TX) +1-650-300-4050 (USA, Palo Alto, CA) 1-855-493-4983 (USA/ Canada HP Customers/Partners) Find a local number<https://join.houston.hp.com/dialin> Conference ID: 437192273 Forgot your dial-in PIN?<https://join.houston.hp.com/dialin> | First online meeting?<http://r.office.microsoft.com/r/rlidOC10?clid=1033&p1=4&p2=1041&pc=oc&ver=4…> Nissa M. Strottman Software, Cloud and Open Source Office of the General Counsel nissa.strottman(a)hp.com<mailto:nissa.strottman@hp.com> T +1 650 857 6279 M +1 650 387 4987 F +1 650 857 5409 Hewlett-Packard Company 3000 Hanover Street MS 1601 Palo Alto, CA 94304-1112 USA [HP]<http://www.hp.com/>

1 0

Re: [legal-discuss] Tracking Openstack Contributions
by Nardozza, Gregg (Gregg) 30 Apr '15

30 Apr '15

Thank you Stefano. I am adding the legal team. Gregg Nardozza [alu-logo-20x20] DMTS - IP Business Development Senior Patent Segment Manager Intellectual Property Business Group Bell Laboratories / Alcatel-Lucent • gregg.nardozza(a)alcatel-lucent.com<mailto:gregg.nardozza@alcatel-lucent.com> This message, intended only for the designated recipient(s), is privileged and confidential. It is intended only for the review of the party to whom it is addressed. If you are not a designated recipient, you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Unintended transmission shall not constitute waiver of the attorney-client privilege or any other privileges. -----Original Message----- From: Stefano Maffulli [mailto:stefano@openstack.org] Sent: Thursday, April 30, 2015 2:25 PM To: Nardozza, Gregg (Gregg) Subject: Re: Tracking Openstack Contributions Hi Gregg, just a clarification: the website stackalytics.com is not managed by OpenStack Foundation nor it's managed by the OpenStack project. Formally the domain is owned by Mirantis and the development is sponsored mostly by the same company. There is an intention to move all the code and data under the wider openstack community umbrella but no plans nor deadlines have been defined. The Foundation extracts records of contributions from the tools used for openstack development (gerrit, launchpad, git, storyboard, mailing lists, etc) and provides that data on http://activity.openstack.org. Regarding the retention policy, I'm not aware of one formal policy for data retention. I would ask the question on legal-discuss(a)lists.openstack.org<mailto:legal-discuss@lists.openstack.org> to get the ball moving towards creating one. Cheers, stef On Thu, 2015-04-30 at 12:07 +0000, Nardozza, Gregg (Gregg) wrote: > Hello Stefano! > > > > I need to know the record retention policy for OpenStack. > > > > We (Alcatel-Lucent) rely on being able to retrieve the information as > shown below from the OpenStack website and need to know the number of > years these records will be publically available and retrievable. > > > > Please let me know who would have this information in the OpenStack > organization or pass this on to whom ever can answer these questions > for me. > > > > Much appreciated. > > > > Gregg Nardozza alu-logo-20x20 > > DMTS - IP Business Development > > Senior Patent Segment Manager > > Intellectual Property Business Group > > Bell Laboratories / Alcatel-Lucent > > *gregg.nardozza(a)alcatel-lucent.com<mailto:*gregg.nardozza@alcatel-lucent.com> > > > > This message, intended only for the designated recipient(s), is > privileged and confidential. It is intended only for the review of the > party to whom it is addressed. If you are not a designated recipient, > you may not review, copy or distribute this message. If you receive > this in error, please notify the sender by reply e-mail and delete > this message. Unintended transmission shall not constitute waiver of > the attorney-client privilege or any other privileges. > > > > > From: MARGOLIN, Udi (Udi) > Sent: Thursday, April 30, 2015 7:53 AM > To: Nardozza, Gregg (Gregg) > Subject: RE: Tracking Openstack Contributions > > > > > You have it all – take for example ‘lbortman’ – follow the link: > > > > > > > > Now you get : > > > > > > > > > > If you follow a specific change ID you get all the details: > > > > > >

4 4

Openstack License Agreement for Users
by Ahmed Ibrahim Al-Oulah 30 Apr '15

30 Apr '15

Dears, Good Day ... We are a openstack user, so what's the license agreement ? Is there another licenses with Apache License 2.0. ________________________________ Ahmed Ibrahem Al Oulah | Systems Engineer | RHCE, VCP-5 | Systems & Platforms, Cloud Services Department STC Advance soultions | P.O. Box 50 | Riyadh 11372 | Saudi Arabia | stcas.com.sa T: +96614600111 ext.1276 | Mob: +966-555449133 | E: aoulah(a)stcas.com.sa Disclaimer: This email communication, and its attachment, may contain confidential information and material and it is intended solely for the use of the addressees listed on it. Un-Authorized Access to this email by anyone else is prohibited. If you are not the intended recipient, please notify us via e-mail at (it(a)stcas.com.sa) and immediately delete the message and its attachments from your system. The views expressed in this email are those of the sender and may not necessarily reflect views of Saudi Telecommunications Company - Advanced Solutions "STCAS". This email communication cannot be guaranteed to be secure or error-free and it is the sole responsibility of the recipient to ensure such. STCAS accepts no liability for any damage caused by any virus transmitted by this email domain.

2 1

ICLA
by Piyanai Saowarattitada 03 Apr '15

03 Apr '15

There appears to be two sections of the same text in the current ICLA. <https://review.openstack.org/static/cla.html> The difference appears being reference to LLCs in the first section. Could someone explain why that is ? Perhaps, there is some text describing the rational already but I just don't know it. If that is the case, please provide pointer. Piyanai Massachusetts Open Cloud <https://review.openstack.org/static/cla.html>

2 1

OpenStack brand and docs site
by Anne Gentle 31 Mar '15

31 Mar '15

Hi all, As the TC continues to add projects to the git openstack namespace, the projects want to publish to docs.openstack.org. Since all of our styling for docs has the OpenStack logo, do we need to take actions to accommodate these projects? Such as: - Require proof signed contract based on definitions at http://www.openstack.org/brand/ from the projects that join through the TC process. - Create doc themes that match definitions for Powered and Compatible that can be applied. - Until these are in place, continue to have those projects publish to Read the Docs or other generic branded sites. I'll bring this up at the TC meeting but I really need legal guidance. Thanks, Anne -- Anne Gentle annegentle(a)justwriteclick.com

2 1

docs licenses: current state and desired state
by Anne Gentle 25 Mar '15

25 Mar '15

Hi all, As promised I investigated the current state of our community guides license indicators and added to the wiki page at https://wiki.openstack.org/wiki/Documentation/ContentSpecs Current states: OpenStack Architecture Design Guide: Apache 2.0 and CC-by-sa 3.0 OpenStack Cloud Administrator Guide: Apache 2.0 and CC-by-sa 3.0 OpenStack Install Guides (all): Apache 2.0 OpenStack High Availability Guide: Apache 2.0 OpenStack Configuration Reference: Apache 2.0 OpenStack Security Guide: CC-by 3.0 Virtual Machine Image Guide: CC-by 3.0 OpenStack Operations Guide: CC-by 3.0 OpenStack End User Guide: CC-by 3.0 OpenStack Admin User Guide: CC-by 3.0 Command-Line Interface Reference: CC-by 3.0 Contributor dev docs (docs.openstack.org/developer/<projectname>): none indicated in output; Apache 2.0 in repo OpenStack API Quick Start: none indicated in output; Apache 2.0 in repo API Complete Reference: none indicated in output; Apache 2.0 in repo Infrastructure User Manual: none indicated in output; CC-by 3.0 in repo Desired state: CC-by 3.0 indicated in the output for all guides. Apache 2.0 also indicated in the output for guides containing code and content. Tasks: Change first five listed guides to CC-by 3.0 in source and output. Change API Quick Start to RST so that cc-by 3.0 can be easily indicated. Questions: On guides where the output doesn't indicate a license but the source does; is that sufficient? Thanks for the help -- I can take the tasks on myself, but would like guidance on whether a license indicator on output is required. Thanks, Anne -- Anne Gentle annegentle(a)justwriteclick.com

3 4

Re: [legal-discuss] [OpenStack-docs] Licensing of documentation
by Steve Gordon 20 Mar '15

20 Mar '15

Adding back legal-discuss as while there were some tangential issues around infra being discussed I believe my core question/concern is most definitely a legal one. ----- Original Message ----- > From: "Steve Gordon" <sgordon(a)redhat.com> > To: "Anne Gentle" <annegentle(a)gmail.com> > > ----- Original Message ----- > > From: "Anne Gentle" <annegentle(a)gmail.com> > > To: openstack-docs(a)lists.openstack.org > > > > > > > > Message: 1 > > > Date: Wed, 18 Mar 2015 08:36:07 +0100 > > > From: Andreas Jaeger <aj(a)suse.com> > > > To: Stefano Maffulli <stefano(a)openstack.org>, > > > openstack-docs(a)lists.openstack.org > > > Subject: Re: [OpenStack-docs] Licensing of documentation > > > Message-ID: <55092AE7.6040207(a)suse.com> > > > Content-Type: text/plain; charset=windows-1252 > > > > > > On 03/17/2015 07:12 PM, Stefano Maffulli wrote: > > > > The conversation has definitely drifted off-topic now :) but I think > > > > it's worth responding here (and eventually move to infra, where it > > > > should continue) > > > > > > > > On Tue, 2015-03-17 at 15:57 +0000, Jeremy Stanley wrote: > > > >> Once we can safely migrate review.openstack.org to > > > >> authenticate against the same openstackid.org identity provider as > > > >> www.openstack.org uses, this should become much simpler again since > > > >> we'll have a way to force contributors to sign up for a foundation > > > >> account (though they'll no longer need to fill out the foundation > > > >> membership form when doing so). > > > > > > > > Indeed, stop using Launchpad and use openstackid.org globally is the > > > > last step we need to accomplish before we can decouple individual > > > > memberships from commit rights. I think we already have all the basic > > > > tools in place to build the list of voters, we need to start thinking > > > > about moving gerrit to use openstackid.org. > > > > > > > > Now, to go back to licensing docs: > > > > > > > > what's the status of licensing for the OpenStack upstream > > > > documentation? > > > > > > > > (I can wait for Anne to come back from holiday if she's the only one > > > > who > > > > can answer this question). > > > > > > ************************** > > > > > > > Sigh, that's not good. I don't want to be the only one who knows this. :) > > > > Technically the docs are still Apache 2.0 because there is no indicator to > > a docs contributor that it would be licensed any other way. (To me, this is > > why we either change the current design or get the transfer underway.) > > What indicator does a contributor get that their contributions are licensed > under Apache 2.0 today? Are we just talking about the marks on the rendered > output (that is, after they already contributed)? > > > Nick Chase did a lot of legwork a few years back looking into what the > > legal need is to get all docs licensed cc-by, and we think we need to have > > all current contributors indicate in writing (somehow) that they license > > the content cc-by. Then the CLA needs to either change or we need a 2nd CLA > > for docs contributions. > > Are we saying here that current contributors to the project have not signed > the CLA? I know this is potentially the case for authors who contributed to > books written in sprints using external tools (Ops Guide, Design Arch Guide) > but ultimately to get into e.g. openstack-manuals someone who has signed the > CLA has to contribute the patch(es) and in doing so grants copyright to the > "Project Manager" no? Maybe I am missing something but I don't understand > why we would need a second CLA here as the existing one doesn't specify a > license either, yet isn't it the mechanism we're using to distribute using > Apache 2.0 today? > > > The desired outcomes are: > > - every reader knows the license > > - all people (corporate contributors, publishers) know if and how to reuse > > the docs > > To be honest from previous discussions (which I believe kicked off Nick's > expedition) I thought we had this nailed but now I'm more confused than when > we started as it seems like we remain in complete limbo on this. Currently > we have: > > - Some books reporting ASL 2.0: E.g. > http://docs.openstack.org/high-availability-guide/content/ > - Some books reporting CC-BY-SA: E.g. > http://docs.openstack.org/openstack-ops/content/ > - Some books reporting BOTH: E.g. > http://docs.openstack.org/admin-guide-cloud/content/ > > ...and I have no idea which ones are correct. The earlier replies seemed to > indicate we should be displaying both, but more recent ones seem to indicate > we should be only displaying ASL 2.0. So in both my roles, as a downstream > and as a contributor I can now count myself as thoroughly confused. > > -Steve > > > - every contributor knows their rights when they write upstream docs > > - contributors are not held liable if the docs are wrong > > - use of the OpenStack brand and logo still go through normal brand > > guidelines > > > > That's all I can think of for now. Let me know if there are additional > > questions or difference in opinion on the outcomes we need. > > > > Anne > > > > _______________________________________________ > > OpenStack-docs mailing list > > OpenStack-docs(a)lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs > > > > -- > Steve Gordon, RHCE > Sr. Technical Product Manager, > Red Hat Enterprise Linux OpenStack Platform > > _______________________________________________ > OpenStack-docs mailing list > OpenStack-docs(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs > -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform

5 10

Licensing of documentation
by Richard Fontana 17 Mar '15

17 Mar '15

Hi, Certain manuals available at docs.openstack.org contain this legal notice: Copyright © 2013 OpenStack Foundation Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. followed immdiately by a box that says: Except where otherwise noted, this document is licensed under Creative Commons Attribution ShareAlike 3.0 License http://creativecommons.org/licenses/by-sa/3.0/legalcode This github repository suggests at quickest glance that Apache License 2.0 is the license: https://github.com/openstack/openstack-manuals Some docs writers at Red Hat were previously under the impression that CC BY was the license of OpenStack documentation, which I assume is incorrect except for material specifically on wiki.openstack.org. Can anyone clarify? We'd like to adapt some portions of the upstream documentation in our product documentation and we want to make sure we get the licensing right. Thanks! Richard Fontana Legal Red Hat, Inc.

4 6

Image Service vs Image service
by Anne Gentle 06 Feb '15

06 Feb '15

I'm working on a patch that will give the Docs team a consistent list of service names to use for projects. https://review.openstack.org/#/c/150030 In it, I'd like to change the name we use in the docs from Image Service to Image service. Are there any legal ramifications for changing the OpenStack doc reference to Image service, lowercase s? We like to provide consistent names rather than project names as much as possible. Thanks, Anne -- Anne Gentle annegentle(a)justwriteclick.com

1 0

CCLA not available anywhere except the non-printable/non-downloadable esign app?
by Luis Villa 05 Feb '15

05 Feb '15

Hey, all- I was trying to look at the CCLA, and there doesn't appear to be a copy of it anywhere other than the e-sign form. Is that deliberate? If not, can it be posted somewhere in a downloadable/printable-for-review format? And of course, if I'm simply missing it, I'd recommend linking to it from the following pages, which is where I looked: https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agre… https://wiki.openstack.org/wiki/HowToUpdateCorporateCLA (The first link has a "preview" of the ICLA but not the CCLA.) Thanks- Luis -- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810 *This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity. For more on what this means, please see our legal disclaimer <https://meta.wikimedia.org/wiki/Wikimedia_Legal_Disclaimer>.*

5 12

Does Openstack provide same legal coverage for projects in Stackforge ?
by Alan Kavanagh 21 Jan '15

21 Jan '15

Hi I previously posted an email http://lists.openstack.org/pipermail/legal-discuss/2014-December/000328.html asking for clarification on the legalities for projects referenced by Openstack and intending to eventually be integrated into main Openstack branch as Openstack Core Projects, but that currently reside in Stackforge. What legal, license, patent troll protection, TM etc would be covered by Openstack for projects in Stackforge? Can someone from the Openstack Legal Team/Openstack Foundation please clarify this? BR Alan

2 1

Legal-discuss
by Alan Kavanagh 22 Dec '14

22 Dec '14

Hi Openstack Can you please advise what the legalities and copyrights, and Openstack Trademarks etc are for projects that live in Stackforge and what Openstack covers for such projects. This question arises due to question I have posted in response to: https://review.openstack.org/#/c/96149/ /Alan

1 0

How should I use pylint (GPL)?
by Angus Lees 12 Dec '14

12 Dec '14

[I'm not subscribed to legal-discuss so I'd appreciate being CCed - or I'll just read it via the archives] Context: https://review.openstack.org/#/c/120320/ pylint is a tool for static analysis of python. It is implemented in python and is GPL (and relies heavily on the 'astroid' library which is also GPL). pylint is/has been widely used by various OpenStack projects by exec'ing it as a simple black-box tool. pylint is only used (in any form) during development and not in a production deployment. In the above change, I have written a custom pylint check and I'd like to write more. Writing a custom pylint check involves importing the pylint/astroid python libraries and calling lots of pylint/astroid python functions. Mark McClain raised the (quite reasonable) concern that this change was importing a GPL'd python library and perhaps couldn't be allowed. I want the freedom to be able to make these new checks completely neutron-specific (or ditto for any other project), so I'd like the code for the checks to be close to the neutron code it is checking and "owned" by the broader neutron development community just like other forms of automated testing. So my key question is: How far does the pylint-importing code need to be before becoming acceptable? I figure my options are roughly: A. Yes, the change above is fine as written, go for it. Importing is most-likely not "deriving" in the GPL-sense and everyone needs to make their own legal assessments at the time they install/redistribute code anyway. B. The above change is fine, go for it. Continue to ensure that any production deployment doesn't require pylint to be installed so this issue never comes up during deployment. C. In the same git repo is fine, but we license these files under GPL and ensure we don't import them from other neutron code. Move the files to their own top-level subdir in the neutron git repo with a big README explanation/warning. ... Z. Move the pylint checks out to a separate git repo on stackforge-or-similar, "release" the checks via pypi, install it in the neutron 'pylint' tox environment, and use it from neutron only through an exec boundary. In the #openstack-neutron IRC discussion regarding this, I fear there's quite a bit of confusion/misunderstanding about copyright and which acts trigger the GPL obligations (and on whom). It would be great to get some authoritative advice here - and perhaps flesh out that FIXME in the legal issues FAQ ;) Thanks! - Gus

1 0

CFP: FOSDEM 2015 Legal & Policy Issues DevRoom
by Richard Fontana 16 Oct '14

16 Oct '14

Hi, The CFP for the FOSDEM 2015 Legal & Policy Issues DevRoom is now out: https://lists.fosdem.org/pipermail/fosdem/2014-October/002036.html and I thought I'd post the link to this list. I believe this list has a mix of lawyers and technical OpenStack contributors and users. I particularly encourage talk proposals from people in the OpenStack technical community even though they might not have thought of giving a 'legal' or 'policy' (in the sense meant here) talk before. I am biased by my interest in OpenStack but in my opinion some of the most interesting legal-policy issues in open source community development are happening in OpenStack and I happen to think that we don't get enough of the technical-community viewpoint when such things are discussed. Richard

1 0

[Horizon] Licensing issue with using JSHint in build
by Aaron Sahlin 10 Sep '14

10 Sep '14

The Horizon build is using JSHint. I am in process of writing JavaScript best practices for Horizon which includes modifying what JSHint Configuration option (rules) are set. Before I consider syncing the Build's JSHint options with the proposed options from the JavaScript best practices (https://review.openstack.org/#/c/117595/) I wanted to double check and be sure Horizon got past the legal problem with the good/evil licensing. Background. JSHint was authored by Douglas Crockford, and he added an extra line in the licensing, "The software shall be used for good, not evil". The issue is in the definition of what is good and what is evil. It is too subjective, what is evil differs from person to person therefore ends up being a liability and leaving users open to frivolous lawsuits. Is this licensing something Horizon needs to be concerned with? If so, did Horizon get permission or find some way around the licensing issue? I had posted this question initially to openstack-dev(a)lists.openstack.org, in which Jeremy Stanley responded with the following which I though was relevant to include. It's worth mentioning that Douglas Crockford seems to consider the free software legal concerns around his license choice amusing and will apparently, upon request, provide an exception to an organization wishing to use his software for evil[1]. He has no interest in changing the situation[2] in JSLint or derivatives (like JSHint) even if that means that they can not be provided as part of Debian[3] or similar legally-concerned distributions. [1]http://dev.hasenj.org/post/3272592502/ibm-and-its-minions [2]https://github.com/jshint/jshint/issues/1234 [3]http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html

4 4

Invitation to working group on FLOSS entities
by Radcliffe, Mark 20 Jul '14

20 Jul '14

If you are interested in attending, you can attend in person at: Mozilla Portland Office Brewery Block 2 1120 NW Couch St Suite 320 Portland, OR 97209 Or you can attend by phone at the Mozilla conference line. There are several options for different US and international numbers and VOIP, full details are here: https://wiki.mozilla.org/Teleconferencing The local option is: US/Oregon/Portland: +1 971 544 8000, extension 92 Once you've dialed in (through any number), the conference number is 271. 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.

1 1

Fwd: need some advise on publicizing a translated version of openstack document.
by Anne Gentle 17 Jul '14

17 Jul '14

Hi legal discussioners, Can you comment on this question? ---------- Forwarded message ---------- From: Jaesuk Ahn <bluejay.ahn(a)gmail.com> Date: Tue, Jul 15, 2014 at 9:45 PM Subject: need some advise on publicizing a translated version of openstack document. To: Anne Gentle <anne(a)openstack.org>, Tom Fifield <tom(a)openstack.org>, Openstack Users <openstack(a)lists.openstack.org> HI Anne and Tom, and everyone here in this mailing list, I do have one question, actually I am relaying a question from someone else in Korea regarding publication of documents. A professor in Korea did translate the entire openstack security-guide document, and he wants to publish translated version as a book with some price tag. He wants to know if he can talk with OpenStack Foundation regarding this commercial publication of OpenStack Document. I told him Document has Creative Common License, and he just needs to follow whatever CC license says. However, if possible, we would like to have some help from you guys =. First, we are not open source license experts. It is a bit tricky to know what CC license exactly means when someone wants to publish “translated version” of a openstack document. Second, he wants to have an opinion form openstack foundation about publication. If you have experienced a similar situation with this one, could you give us some hints or advise? Thank you. Jaesuk Ahn | Ph.D. Senior Director | Co-Founder cloud4u, Inc. *… active member of openstack community *

5 4

Appropriate use of OpenStack CCLA Schedule B...
by McCullough, Theodore 08 Jul '14

08 Jul '14

Hi Folks: I am interested in using the CCLA Schedule B as a vehicle to make contributions as per the OpenStack CCLA- "Contribution" shall mean the code, documentation or other original works of authorship expressly identified in Schedule B..." Currently, my thought is to post in the GIT Commit Message accompanying the contribution, "Per the terms of the CCLA, this is a CCLA Schedule B Submission" or "CCLA Schedule B Submission". I would like some feedback regarding using the Schedule B to make contributions. Thank you in advance for your thoughts. Best regards, -T. Ted McCullough Senior IP Counsel, EMC Corporation 2831 Mission College Blvd. Santa Clara, CA 95054 Email- Theodore.mccullough(a)emc.com<mailto:Theodore.mccullough@emc.com> Direct- 408.566.7936 Mobile- 206.595.2502 **THIS EMAIL MAY CONTAIN ATTORNEY-CLIENT PRIVILEGED COMMUNICATIONS AND/OR ATTORNEY WORK PRODUCT** [cid:image001.png@01CF9A0F.684D7F50]

2 1

Appropriate use of OpenStack CCLA Schedule B...
by McCullough, Theodore 08 Jul '14

08 Jul '14

Hi Folks: I am interested in using the CCLA Schedule B as a vehicle to make contributions as per the OpenStack CCLA- "Contribution" shall mean the code, documentation or other original works of authorship expressly identified in Schedule B..." Currently, my thought is to post in the GIT Commit Message accompanying the contribution, "Per the terms of the CCLA, this is a CCLA Schedule B Submission" or "CCLA Schedule B Submission". I would like some feedback regarding using the Schedule B to make contributions. Thank you in advance for your thoughts. Best regards, -T.

2 1

Orange SA : Openstack contribution's process for a supplier of Orange
by christophe.martinez＠orange.com 07 Jul '14

07 Jul '14

Dear Mr/Mrs/Ms, Your address was giving to me by Stefano Maffulli (OpenStack Foundation). Pleased find, attached to this email, my exchange with Stefano. I'm writing because we signed a CCLA in July or August 2013 with OpenStack (see the documents signed attached to this email) in order to contribute to the community and we are working with a supplier which will be a contributor in the OpenStack community. So we would this supplier contributes directly and on behalf of Orange to your Community. Therefore, Orange has done everything with its supplier in order to give it the rights to contribute on behalf of Orange SA. By the way, we have read within the CCLA (item 4 in the CCLA signed by Orange, pleased find my attached file on this email) this sentence : "You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation." You talk about "employees of the Corporation" but what does it means about an employee of a supplier of Orange SA? Supposing that supplier has all the rights by Orange to contribute on behalf of Orange within OpenStack community. Is it possible to add directly the name and the address (email, phone etc.) of the employee(s) of the supplier in the Orange SA's contributors CLA list? Thank you for your help and do not hesitate to ask us if you require any further informations. Regards, Christophe Martinez. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 1

CLA Schedule
by Radcliffe, Mark 23 Jun '14

23 Jun '14

I have received some additional information on adopting the Apache license as a contribution agreement and I want to make sure that I have the time to follow up, so I will be deferring delivery of the framework memo to the Legal Committee until July 7 for review at the July 9 meeting. We will then post it to a site available to the community. Since we have more time I would be interested in continuing to receive information on projects that have adopted the Apache Software License (not the CLA) as their contribution agreement. I am particularly interested in projects that have reviewed the legal issues arising in such a change (and the contact information of the relevant lawyers). I need to get this information by noon PST on June 27 in order to be able to follow it up. Thanks. 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.

1 0

[Fwd: [openstack-dev] mysql/mysql-python license "contamination" into openstack?]
by Mark McLoughlin 21 Jun '14

21 Jun '14

Forwarding a question from openstack-dev about the implications of our use of mysql-python, which is a GPLv2 licensed library. We've had some previous threads about GPL licensed dependencies e.g. http://lists.openstack.org/pipermail/openstack-dev/2013-March/006772.html http://lists.openstack.org/pipermail/openstack-dev/2013-March/006792.html http://lists.openstack.org/pipermail/openstack-dev/2013-March/006908.html Mark. -------- Forwarded Message -------- > From: Chris Friesen <chris.friesen(a)windriver.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: [openstack-dev] mysql/mysql-python license "contamination" > into openstack? > Date: Thu, 12 Jun 2014 12:13:05 -0600 > > Hi, > > I'm looking for the community viewpoint on whether there is any chance > of license contamination between mysql and nova. I realize that lawyers > would need to be involved for a proper ruling, but I'm curious about the > view of the developers on the list. > > Suppose someone creates a modified openstack and wishes to sell it to > others. They want to keep their changes private. They also want to use > the mysql database. > > The concern is this: > > nova is apache licensed > sqlalchemy is MIT licensed > mysql-python (aka mysqldb1) is GPLv2 licensed > mysql is GPLv2 licensed > > > > The concern is that since nova/sqlalchemy/mysql-python are all > essentially linked together, an argument could be made that the work as > a whole is a derivative work of mysql-python, and thus all the source > code must be made available to anyone using the binary. > > Does this argument have any merit? > > Has anyone tested any of the mysql DBAPIs with more permissive licenses? > > Chris > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

4 6

[Fwd: Re: [openstack-dev] mysql/mysql-python license "contamination" into openstack?]
by Mark McLoughlin 13 Jun '14

13 Jun '14

-------- Forwarded Message -------- > From: Mike Bayer <mbayer(a)redhat.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] mysql/mysql-python license > "contamination" into openstack? > Date: Thu, 12 Jun 2014 15:30:00 -0400 > > On Thu Jun 12 14:13:05 2014, Chris Friesen wrote: > > Hi, > > > > I'm looking for the community viewpoint on whether there is any chance > > of license contamination between mysql and nova. I realize that > > lawyers would need to be involved for a proper ruling, but I'm curious > > about the view of the developers on the list. > > > > Suppose someone creates a modified openstack and wishes to sell it to > > others. They want to keep their changes private. They also want to > > use the mysql database. > > > > The concern is this: > > > > nova is apache licensed > > sqlalchemy is MIT licensed > > mysql-python (aka mysqldb1) is GPLv2 licensed > > mysql is GPLv2 licensed > > > > > > > > The concern is that since nova/sqlalchemy/mysql-python are all > > essentially linked together, an argument could be made that the work > > as a whole is a derivative work of mysql-python, and thus all the > > source code must be made available to anyone using the binary. > > > > Does this argument have any merit? > > the GPL is excepted in the case of MySQL and other MySQL products > released by Oracle (can you imagine such a sentence being > written.....), see > http://www.mysql.com/about/legal/licensing/foss-exception/. If > MySQL-Python itself were an issue, OpenStack could switch to another > MySQL library, such as MySQL Connector/Python which is now MySQL's > official Python driver: > http://dev.mysql.com/doc/connector-python/en/index.html > > > Has anyone tested any of the mysql DBAPIs with more permissive licenses? > > I just mentioned other MySQL drivers the other day; MySQL > Connector/Python, OurSQL and pymysql are well tested within SQLAlchemy > and these drivers generally pass all tests. There's some concern over > compatibility with eventlet, however, I can't speak to that just yet. > > > > > Chris > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev(a)lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

Copyright statements in source
by Rich Bowen 12 Jun '14

12 Jun '14

Stefano suggested that I bring this to the legal-discuss list. I know that this has been discussed in the past, so I don't anticipate a great shift in sentiment, but it seemed worth discussing. My full thoughts are on my blog - http://drbacchus.com/copyright-statements-in-source-files - and I know some of you have seen this discussed on the docs mailing list, or seen it on planet.openstack Anyways, it has been my experience in Open Source communities that having a copyright statement at the top of a source file can be very off-putting to people who want to contribute to that file, due to the perception that it is "owned" by someone in particular. The statement is not necessary: copyright law ensures that contributors have copyright on the content that they author, and git keeps a permanent record of who contributed what. Some folks have claimed (the last time this came up on this list) that the statement was necessary, and this is not the case. It's also unscalable - think in terms of 10 years from now when every file potentially lists hundreds of copyright holders - or perhaps only those who saw fit to add their name to the growing list. What would this contribute? And if people are contributing solely for recognition - which seems at least part of the motivation for a copyright statement, perhaps 1) they're missing the point of Open Source and 2) we should provide a more public means of thanking the enormous list of contributors, rather than having it scattered across thousands of files that relatively few people will ever see. -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://openstack.redhat.com/

15 39

OpenStack and its CLA
by Radcliffe, Mark 12 Jun '14

12 Jun '14

One recent development of interest was Joyent's removal of the CLA for node.js http://www.joyent.com/blog/broadening-node-js-contributions. Please note that node.js is licensed under MIT so not an exact analog. 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.

3 2

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

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

31 Mar '14

> On 3/20/14, 8:22 AM, Richard Fontana wrote: > > On Thu, Mar 20, 2014 at 08:22:12AM +0000, Mark McLoughlin wrote: > >> I'm no fan (personally) of AGPLv3, but taking a stance that there must > >> be a way of deploying OpenStack in production without requiring any > >> AGPLv3 code to be deployed is a significant policy decision for the > >> project and I don't think we've ever articulated the reasons clearly for > >> it. > > Such a policy would be unprecedented for any Apache License 2.0 > > project as far as I am aware. For comparisons look at the legal > > policies of the Apache Software Foundation, which don't go this far. > > > Such a policy needs to be made on a project-by-project basis, as well, > especially w/r/t AGPL code. MongoDB/10Gen has communicated very clearly > where they consider their copyright boundary to exist, and I believe > that legally that functions as a waiver/license if they would ever end > up being wrong (which I don't think they would, as I believe a network > communication creates a copyright boundary). > Thanks, > Van The ASF has been dealing with optional dependencies and their license interactions with the Apache License for a long time. They have formed at the least more "in depth" documentation on how all of it interacts, specifically as it relates to the issues presented here, I think it is reasonable to refer to: http://www.apache.org/legal/resolved.html#optional "Will the majority of users want to use my product without adding the optional components?" This is clearly false in the case of Marconi as it stands today. MongoDB might be "optional", but it is the only realistic choice. An additional document that hasn't quite moved all the way through the ringer, and hence still "proposed" at the ASF is this one: https://www.apache.org/legal/3party.html The contents of the Guiding Principles seem perfectly aligned with OpenStack. I think it also does a good job of laying out both groups of licenses based on their properties, and how projects can depend on or build modules with mixed license dependencies. Things like classifying "System Requirements" are a good fit for projects like Nova, which have many plugins for restricted licensed Hypervisors for example. I would love to help see this kind of documentation get added to the Legal FAQ / references for OpenStack. What is the best set of actions to get there? Port the "LegalIssuesFAQ"[1] to a git report and start proposing changes in a Code Review? Thanks, Paul [1] - https://wiki.openstack.org/wiki/LegalIssuesFAQ

2 1

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

27 Mar '14

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

1 0

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

27 Mar '14

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

1 0

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

24 Mar '14

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

6 10

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

21 Mar '14

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

3 2

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

20 Mar '14

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

2 1

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

20 Mar '14

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

5 10

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

20 Mar '14

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

6 5

Contribution Snag
by Radcliffe, Mark 19 Feb '14

19 Feb '14

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

2 1

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

10 Feb '14

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

11 37

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