June 2014 - legal-discuss - lists.openstack.org

Licensing of documentation
by Richard Fontana 16 Mar '15

16 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

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 12 Jun '14

12 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 31 May '14

31 May '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