Open Stack

----- Original Message ----- 
> From: "Anne Gentle" <annegentle at gmail.com>
> To: "Steve Gordon" <sgordon at redhat.com>
> On Wed, Mar 18, 2015 at 4:47 PM, Steve Gordon < sgordon at redhat.com > wrote:
> > ----- Original Message -----
> 
> > > From: "Nick Chase" < nchase at mirantis.com >
> 
> > > First off, I can't speak to the Ops Guide but the Design Arch Guide was
> 
> > > all people who'd signed the CLA, I believe, though that's by
> 
> > > happenstance and not by any causation.
> 
> > >
> 
> > > As far as what I remember about the previous expedition:
> 
> > >
> 
> > > In order for us to officially change the license, we needed to find a
> 
> > > way to:
> 
> > >
> 
> > > a) Add the new license to the overall CLA and get everyone to sign it
> 
> > > b) Get everyone to sign a separate new CLA that specified the new license
> 
> > > or
> 
> > > c) Find a way to ensure that new contributors knew that their content
> 
> > > was going under a different license than the code.
> 

> > Per other comments, this seems like an odd requirement given how we
> > currently
> > handle the code - that is the CLA certainly doesn't specify that we're
> > using
> > ASL 2.0 today.
> 

> > > Making things further complicated was the fact that some books (the API
> 
> > > Guide?) have substantial amounts of code and need to ALSO have the ASL,
> 
> > > even if we add the CC-BY for the prose part.
> 

> > Currently the API Reference is actually the example of a guide that doesn't
> > expose any license boiler plate at all, ASL 2.0 or otherwise (fun).
> 
> > > And of course any license changes needed to be approved by the board,
> 
> > > which is, I think, where we eventually ran aground.
> 

> > This is where I get confused because things go a bit circular. Using CC-BY
> > for documentation was already approved by the board, in 2012 no less
> > [1][2],
> > and at some point (apparently) a letter was drafted to the board explaining
> > the steps required to execute (I assume this was the outcome of your work)
> > but it's unclear to me what if anything happened next. Was it presented to
> > the board and rejected?
> 

> > > That, and I think the final question was, "Why do we need to do this,
> 
> > > again?"
> 

> > This pre-dates my involvement, and Anne only touches on it in the email I
> > can
> > find [1], but from my point of view even if the ultimate answer is no we
> > want to stick with ASL 2.0 for documentation we need to resolve the current
> > hodge podge of licenses being exposed on docs.openstack.org . We currently
> > have examples of all of these cases:
> 

> > - Guides that expose ASL 2.0.
> 
> > - Guides that expose CC-BY-SA 3.0.
> 
> > - Guides that expose both.
> 
> > - Guides that expose no license at all.
> 

> > What's still not clear to me at the moment is *how* to proceed with that.
> 
> Okay, I think we're getting closer to what we want. Then we can put a plan in
> place for the outcomes.
>
> I personally want contributors to understand how their doc contributions get
> licensed, but perhaps the output is the only way to do that.
>
> Some guides will purposely expose both due to having code and content, is
> that problematic for you still Steve?

Per Richard I'm not sure it's *necessary* but I don't believe it's a problem either. Perhaps though if doing this it would be good to make it clear in the boilerplate what is licensed as CC-BY (the prose) and what is licensed as ASL (code samples) and use that across the board? Ideally what I would like to get away from is having inconsistent licensing headers across the docs suite leading to the question "is this intentional/reliable".

> I checked on the CC-By ability of the clouddocs-maven-plugin and it can do
> CC-by, but only 3.0 currently. Bug logged:
> https://bugs.launchpad.net/openstack-manuals/+bug/1433868

My recollection is we were always after 3.0 so while future proofing the toolchain is good I think this is OK for now :).

> How about this: I'll take a stab at the desired state for each guide. Then
> for each guide we can say what has to be done to get to desired state.

That would be great, I think this would be very helpful for framing where we go next.

> I'll use https://wiki.openstack.org/wiki/Documentation/ContentSpecs as a
> starting point. I won't write up a blueprint or spec yet since this is
> "just" bug fixing for now, as long as we get agreement on each guide's
> license.

> The only place where I still need legal guidance is whether I need an
> audit-able trail for the license assignment, does anyone know? For example,
> if I change the Ops Guide to CC-by, do I have to get agreement from all the
> contributors to the Ops Guide?

I'm also not sure on this, like Nick I think everyone who was involved in the Arch Design Guide, by co-incidence, had signed the CLA (we should verify this though) and this should alleviate this concern but I am unclear on whether the same holds for the Ops and Security guides.

Thanks,

Steve

> Let me know your thoughts. Thanks all for the input.

> Anne

> > -Steve
> 

> > [1]
> > http://lists.openstack.org/pipermail/openstack-docs/2013-September/002904.html
> 
> > [2]
> > https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#Approval_of_the_CCBY_License_for_Documentation
> 

> > > > >
> 
> > > > > > 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.
> 
> > > > >
> 
> > > >
> 
> > > >
> 
> > > > So sorry Steve, it _is_ confusing.
> 
> > > >
> 
> > > > I'll give this my full attention when I'm back next week. Feel free to
> 
> > > > get more clarification here though! It's completely possible I'm not
> 
> > > > remembering everything.
> 
> > > >
> 
> > > > Anne
> 
> > > >
> 
> > > > > -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 at lists.openstack.org
> 
> > > > <mailto: OpenStack-docs at 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 at lists.openstack.org
> 
> > > > <mailto: OpenStack-docs at 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 at 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
> 

-- 

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform