- legal-discuss - lists.openstack.org

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

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