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

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

Copyright statements in source
by Rich Bowen 13 Jun '14

13 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

Re: [legal-discuss] Trivial contributions and CLAs
by Jonathan Bryce 24 Apr '14

24 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 24 Apr '14

24 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 14 Apr '14

14 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