- legal-discuss - lists.openstack.org

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

Need for "All rights reserved" in source files ?
by Daniel P. Berrange 27 May '14

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